Am 31.08.2010 22:53, schrieb Joerg Wunsch: > Johannes Bauer <jb....@gmx.de> 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 _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
