This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430 compiler 4.3.5 RTS has wrong stack size reported by call_graph for __mspabi_divul

The post http://e2e.ti.com/support/microcontrollers/msp430/f/166/p/380534/1347497.aspx#1347497 is a MSP430 program where call_graph reports a maximum stack size of 100 bytes, when in fact the maximum stack size is 104 bytes.

From investigation in that thread, the incorrect total stack size occurred because the leaf function which caused the maximum stack size,  __mspabi_divul, had a reported stack frame size of 8 bytes instead of the actual 12 bytes used.

When the stack_usage directive is used in an assembler source file, is the value set in stack_usage supposed to be just the size of the variables allocated on the stack or should the value include the return address on the stack?

i.e. is the error in the source for the __mspabi_divul assembler function, or the assembler not adding on the size of the return address to the value in the stack_usage directive?

[I haven't checked to see if any other assembler RTS functions also have the wrong stack frame size reported]

  • That's a good question. I'm going to have to ask some experts.

    I looked at the source code for other hand-coded assembly functions in the RTS, and it looks like they all consider only the stack space explicitly created by the function, ignoring the return address pushed by the CALL, so divul is not out of line in that regard.

  • I think the problem is a mistake in the hand-coded assembly routines for 32-bit long divide.  I filed SDSCM00051179 in the SDOWP system to have this issue investigated.  Feel free to follow it with the SDOWP link below in my signature.

    Thanks and regards,

    -George