RFC: stack trace generation

[Andrew Haley]

Casey Marshall writes:
 > >>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:
 > 
 > Andrew> Casey Marshall writes:
 > 
 > >> 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.
 > 
 > Andrew> My first reaction to this is that I'm a bit reluctant to put
 > Andrew> DWARF2 parsing into libgcj, but if that's agreed by common
 > Andrew> consent to be a good solution I won't argue.
 > 
 > I think I recall seeing a message to the effect that libgcj should
 > have something like this, but had to do it without using things (like
 > libbfd) that have incompatible licenses.
 > 
 > Andrew> However, if we can fix this PLT problem with a change to gcc I
 > Andrew> believe that the reflection metadata was is the right way to
 > Andrew> go.  To a large extend the DWARF debug info and the reflection
 > Andrew> metadata are redundant, but we support metadata on every
 > Andrew> target and DWARF info on only some of them.
 > 
 > In that case I'd rather see the metadata be used instead of this,
 > which is admittedly rather hairy and convoluted. In the meantime I
 > will be doing it this way.
 > 
 > What are the current issues then

This is my understanding:

When you call a shared library, you jump via the PLT.  The PLT is a
list of jump instructions that initially point to the dynamic loader
but are replaced by direct jumps to library routines.  When you take
the address of a routine, you get the address of a PLT entry, not the
address of the routine itself.  This is true even if the routine you
take the address of is in the same compliation unit.

Therefore, with current gcc semantics, it is impossible to get the
true address of a routine that is declared to be global, and this
causes great problems for the unwinder because the class metadata for
methods points to PLT entries, not to the code for the methods.  So,
when we have a code address on the stack we can't find out which
method it is associated with.  AFAIK we need to make a change to gcc's
internals to fix this.

I may have some of this wrong, in which case I'm sure Bryce will
correct me!

 > and what does PLT stand for?

Procedure Lookup Table.

Andrew.