In addition to SF bug 3168453 which notes that the prototype for
__get_frame_address() in msp430-libc is wrong (and has been for years)
resulting in a reference to a non-existent external function, SF 3198920
documents that the whole implementation of everything associated with the
frame pointer turns out to be horribly shakey, including the
_BIC_SR_IRQ-style routines that set the value of SR on interrupt returns.
(Specifically, the wrong location might be produced if anything adjusts the
stack pointer within the routine, including use of alloca(3) or calling
functions that require pushing arguments onto the stack or reserving space
for returned values that don't fit in registers.)
I'll have to fix the issues related to __bic_sr_irq(), but I'm inclined to
discard the mspgcc-specific __get_frame_address() and defer to the standard
__builtin_frame_address that's part of gcc.
If you want a __get_frame_address() capability in mspgcc, what do you want
to do with it? Do you want the stack address of the first auto-class
variables defined in the function? Note that callee-saved registers might
precede this region. Do you want the stack address where the return address
is stored?
What do you want to do with the frame address if you have it?
Peter
------------------------------------------------------------------------------
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
