[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: |
Wed, 01 Sep 2010 10:40:29 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 |
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
- Re: [avr-gcc-list] Frame pointer location,
Johannes Bauer <=