RFC: stack trace generation

[Andrew Haley]

Per Bothner writes:
 > Andrew Haley wrote:
 > 
 > > 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.
 > 
 > Why can't you can have a target-dependent helper routine that can
 > extract the real function address from a PLT entry?

That's one way of solving it, but I was thinking of changing gcc so
that when we write class metadata we write actual code addresses, not
PLT addresses.  I don't think there's an great difficulty in making
such a change, and I don't think it would break anything in gcj.

Andrew.