Re: RFC: stack trace generation

[Andrew Haley <aph at redhat dot com>]

Bryce McKinlay writes:
 > Andrew Haley wrote:
 > 
 > > > 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.
 > >
 > >My first reaction to this is that I'm a bit reluctant to put DWARF2
 > >parsing into libgcj, but if that's agreed by common consent to be a
 > >good solution I won't argue.  
 > >  
 > >
 > >However, if we can fix this PLT problem with a change to gcc I believe
 > >that the reflection metadata was is the right way to go.  To a large
 > >extend the DWARF debug info and the reflection metadata are redundant,
 > >but we support metadata on every target and DWARF info on only some of
 > >them.
 > >  
 > >
 > Class metadata will be used to implement the IP->method/class mapping. 
 > Dwarf2 will be used to implement Throwable.printStackTrace(), ie the 
 > IP->source file/line number mapping. This replaces the call to addr2line 
 > which is quite inefficient and adds a dependency on an external tool. 
 > So, I think the Dwarf2 solution is the way to go.

Sounds reasonable.  We can't insist that in order for libgcj stack
traces to work we must use a specific debug info format.  However, if
all we lose on non-DWARF 2 platforms is line numbers/ source files I
can't see any big objection.

One thing I should point out for lurkers: we're using DWARF 2 to mean
two different things here: DWARF 2 unwinder data and DWARF 2 debug
info.  If we can do everything except printStackTrace() with the
former, that's unlikely to cause problems.

One other thing: as long as we stick to the unwinder library in libgcc
we'll be able to cope with platforms like ARM and IA-64, which have
their own ideas about unwinder info.

Andrew.