RFC: stack trace generation

[Casey Marshall]

>>>>> "Bryce" == Bryce McKinlay <mckinlay@redhat.com> writes:

Bryce> Casey Marshall wrote:
>>  Hmm, "Bryce is working on it" seems like it's the answer I've been
>> getting for a while now ;)
>> 
>> What I was more interested in was changing the file/line lookup
>> code in NameFinder, and whether or not a shared library DWARF-2
>> parser would be a part of that. I've improved what I posted earlier
>> a great deal, so it is not unreasonably slow, and produces fairly
>> accurate debug traces.
>> 

Bryce> Dude, this patch is awesome!

Bryce> As Andrew mentioned, I have already rewritten a large part of
Bryce> the stack trace infrastructure to be simpler and to use the
Bryce> Dwarf2 unwinder. It still has a few issues, such as the PLT
Bryce> issue (see below), and that it will not work on platforms that
Bryce> are not using the dwarf2 unwinder (namely Windows). I have
Bryce> simplified NameFinder substantially but currently was still
Bryce> using addr2line for name lookup, which is too slow to open
Bryce> large shared libraries like libgcj.so. Despite these problems,
Bryce> I'm considering checking in the new stack tracer soon. Given
Bryce> the benefits of good shared library and interpreter stack
Bryce> traces, I think its better to get the code in despite the
Bryce> problems, which aren't really any worse than those with the
Bryce> existing code.

What I'm trying now is making the file/line number lookup code do so
for the stack as a whole -- each `lookup' method in NameFinder would
receive the entire stack trace and an array of objects to store the
info it finds for each frame, skipping frames that have already been
filled in. Then I call each in a precedence order -- interpreted,
DWARF-2 info, dladdr, and finally (not implemented yet) addr2line.

This makes the DWARF-2 part much faster, since it can optimize out of
having to read things more than once. It also has room for inserting
other methods for finding debug info; it isn't "pluggable", but it
could be.

Bryce> I think reading the .debug_line info directly is definitely the
Bryce> right solution. My only concern is this: + * DWARF-2 reading by
Bryce> Casey Marshall <csm@gnu.org>. ELF info reading + * based on
Bryce> elf/sprof.c from glibc-2.3.2, written by Ulrich Drepper + * and
Bryce> Copyright (C) 1997-2002, 2003 Free Software Foundation, Inc.

Bryce> Are we allowed to use this ELF code? Do we need to get special
Bryce> permission from the FSF to use/relicense it?

Maybe, that was one of my open questions about this. The code I used
from glibc was very small -- basically a cluestick about how to mmap
the ELF headers, and how to find and inspect section names.

I could rewrite this part if need be, since I have a better grasp of
ELF than when I started this.

-- 
Casey Marshall || csm@gnu.org