Re: RFC: stack trace generation

[Bryce McKinlay <mckinlay at redhat dot com>]

Casey Marshall wrote:

> Andrew> Casey Marshall writes:
>  
>
> > > Something I've been working on recently is finding a way to get a
> > > decent Java stack trace, complete with file and line number
> > > information, without using external processes (the problems with
> > > GCJ's Process implementation notwithstanding, the current method is
> > > too slow, and doesn't work on my target platform when a lot of the
> > > code is in shared libraries).
> > >      
>
> Andrew> Bryce has been working on a patch for this for some time now.
> Andrew> It's different from what you have because it uses gcj's
> Andrew> reflection data.  I'm pretty sure that this is the right way
> Andrew> to go.  However, there have been a few problems with PLT
> Andrew> entries.
>
> 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.
>  

Dude, this patch is awesome!

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

I think reading the .debug_line info directly is definitely the right 
solution. My only concern is this:


+ * DWARF-2 reading by Casey Marshall <csm@gnu.org>. ELF info reading
+ * based on elf/sprof.c from glibc-2.3.2, written by Ulrich Drepper
+ * and Copyright (C) 1997-2002, 2003 Free Software Foundation, Inc.


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

> Also, what is the status of Mark's interpreted frame info patch?
>  
I've changed the way interpreter stack traces work also, and will be 
integrating marks line-number lookup code.

> What are the current issues then, and what does PLT stand for? I'd
> like to understand better what you mean.
PLT = Procedure link table. Its the table of trampoline code that the 
linker uses to implement calls from non-PIC to PIC code. The problem is 
that, in certain circumstances, the function pointer that the linker 
gives us in a _Jv_Method object does not point to the function itself 
but rather a PLT entry for that function. This means we can't associate 
the function pointer returned from the dwarf2 unwinder with the 
_Jv_Method it belongs to, since the pointer comparison fails. There are 
ways to around this, eg using PC-relative encoding for the method 
pointers in our class metadata, but they are dependent on compiler 
changes associated with the BC work.

As for the problems with platforms that do not use Dwarf2, I think the 
only sane way to fix them may be to emit class metadata containing the 
addresses of both the beginning and end of each function - we can then 
implement the instruction pointer -> _Jv_Method lookup directly in 
libgcj instead of requiring the Dwarf2 FDE.

Regards

Bryce