[Top][All Lists]
[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