This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: stack trace generation


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? I realize there is performance cost, but (for example) it should be possible to do this mapping at class init time. -- --Per Bothner per@bothner.com http://per.bothner.com/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]