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

[Johannes Bauer]

Am 31.08.2010 22:53, schrieb Joerg Wunsch:
> Johannes Bauer <address@hidden> wrote:
> 
>> When sporadic deadlocks occur in a system, a stacktrace can really
>> help find bugs.
> 
> Yes, I know.  I usually end up in manually inspecting the stack then,
> as this requires no specific compilation options.

Well, there are times when such deadlocks occur *really* sporadic, far
too sporadic to have a JTAG connected all the time. If the frame pointer
issue were resolved, it would give users the ability to compile a
stacktracing (debug) and a non-stacktracing (production) version.

> As I only have to do it once a year or so, this never bothered me too
> much (and I could successfully dig up memory corruptions going into IO
> space that way, which in turn triggered an unexpected interrupt, and
> other "nice" gotchas).

This requires that you're connected via JTAG, however.

>> I think stack unwinding in-system could be useful for
>> other people as well.
> 
> Well, most people debug using AVR Studio, which has even less ideas
> about the GCC call stack than AVR-GDB does.  AVR Studio even lacks the
> ability to display out-of-scope variables, yet most people appear to
> just live with that.

I'm not one of those users appearently :-) I develop using Linux and
never really found AVR Studio nice to use (although their inspection of
internal registers and how they display it is admittedly excellent).

> I doubt there's a very broad audience for
> improved stackframes -- as I said, people do care for the amount of
> code generated, next they do care for the code size, then they compare
> the generated code size with compiler XYZ, and only then they start
> comparing other features. :-/

Well I really do not think that argument is valid - if you want
stackframes you have to *explicitly* enable them
(-fno-omit-frame-pointer) and therefore you probably know what you're
doing. Compiling with >= -O2 implies -fomit-frame-pointer and therefore
the code size is reduced accordingly.

I really do not think that it would cause gcc a bad reputation since it
already is the case that the code size increases with
-fno-omit-frame-pointer - the only change would be that a stackunwinding
in-system would actually be *possible* instead of impossible.

Imagine how amazing it would be if after a WDR the system would tell you
where it had last been - it's all implemented here already (including
the stack unwinding) until I noticed that the FP moves around depending
on the function :-(

>> Could you please point me to where I should look/poke around in
>> order to get this resolved?
> 
> Sorry, I'm not a compiler guy.  I don't have any clues about the
> compiler internals.

:-(

But this is the right list to ask this question, isn't it? Is there
someplace else I could go to get help or anyone specific I could ask? I
really don't just want it done for me, just pointing me to where I'd
have to look and I might be able to fix that on my own.

Kind regards,
Johannes