In message: <20101002210346.GE27937(a)bitmover.com>
Larry McVoy <lm(a)bitmover.com> writes:
: > > If you could look at the stack frames and give me a stack trace
: > > that's more or less the same thing.
: >
: > (gdb) bt
: >
: > The real question is not to get a stack trace, but to analyse it.
:
: Hmm, we seem to have a different view. I like people who can write
: the gdb bt code, not run it. This isn't an imaginary thing, one of
: my guys showed up one day with his own hand rolled backtrace that we
: ended up putting in our product for support.
:
: The advantage of his, over the following hack we had before, was that
: it worked when no gdb was installed (windows):
:
: void
: gdb_backtrace(void)
: {
: FILE *f;
: char *cmd;
:
: unless (getenv("_BK_BACKTRACE")) return;
: unless ((f = efopen("BK_TTYPRINTF")) ||
: (f = fopen(DEV_TTY, "w"))) {
: f = stderr;
: }
: cmd = aprintf("gdb -batch -ex backtrace '%s/bk' %u 1>&%d
2>&%d",
: bin, getpid(), fileno(f), fileno(f));
:
: system(cmd);
: free(cmd);
: if (f != stderr) fclose(f);
: }
Stack back traces are easy on x86, but get a lot harder on !x86 at
high optimization layers without help from libunwind. That's the down
side of not relying on gdb... :)
Warner