avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] Frame pointer location


From: Johannes Bauer
Subject: Re: [avr-gcc-list] Frame pointer location
Date: Tue, 31 Aug 2010 12:42:48 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4

Am 15.08.2010 09:02, schrieb Joerg Wunsch:
> Johannes Bauer <address@hidden> wrote:
> 
>> I've got another question regarding the AVR ISR prologues: Let's say
>> I compile with -fno-omit-frame-pointer.
> 
> As a side note, I don't think this option has received extended
> testing in AVR-GCC.  People are usually interested in getting the
> smallest code size possible, so creating a stack frame when it's not
> really needed (many functions don't need it) is a waste of time and
> code.

When sporadic deadlocks occur in a system, a stacktrace can really help
find bugs. In an application, this is currently the case for me. If I
could produce an effective stacktrace, this would help immensely.

However, a frame pointer with arbitrary displacement from the return
address is quite useless. I tried patching the avr-gcc and managed to
move the FP to the beginning of the prologue, but all references to the
Y-Ptr still are the same (and I didn't find out how to change that).
Changing the initial_elimination_offset return value to reflect the new
values did not change the output at all, playing around with
avr_hard_regno_mode_ok and legitimate_address_p did affect the way the
code is generated (i.e. copying the value from Y to X, doing arithmetic,
dereferencing X), but ultimately the actual offset which was used
remained the same.

Could you please point me to where I should look/poke around in order to
get this resolved? I think stack unwinding in-system could be useful for
other people as well.

Kind regards,
Johannes



reply via email to

[Prev in Thread] Current Thread [Next in Thread]