On Thu, Mar 3, 2011 at 3:22 PM, Peter Bigot <[email protected]> wrote:
> 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?
What I want is to be able to reliably find the return address of my caller.
My immediate
need is used in a crash writer. Although this can get dealt with in a
different way if
__get_frame_address()/return address capability isn't available.
> 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?
>
Doesn't matter as long as there is a consistent reliable way to obtain the
return address etc.
>
> 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
>
>
--
Eric B. Decker
Senior (over 50 :-) Researcher
------------------------------------------------------------------------------
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
