Java stack trace vs. the PLT

[Bryce McKinlay <bryce at mckinlay dot net dot nz>]

For stack traces, security checks, etc, libgcj needs to associate the 
IP address of a method with the class which it belongs to. One of the 
techniques we use to do this (and the one I am hoping to use 
exclusively in future) is to build a hashtable of all the method entry 
points (called "ncode"s in libgcj) for each initialized class. The 
ncode values are obtained through the _Jv_Method descriptor which the 
GCJ compiler generates for every method. It looks like this:

struct _Jv_Method
{
  _Jv_Utf8Const *name;
  _Jv_Utf8Const *signature;
  _Jv_ushort accflags;
  _Jv_ushort index;
  void *ncode;
  _Jv_Utf8Const **throws;
}

For the most part this is working nicely, but there is a problem. iff 
the main program binary has a fixed reference to a method in a shared 
library, the value that the dynamic linker puts in for ncode is in the 
address space of the main binary - a PLT entry, I presume.

This means that non-virtual methods in a shared library (including 
libgcj) that are called directly by the main program do not appear in 
stack traces, because the ncode value used in the hashtable is not the 
real address of the function!

Is there anything we can do to ensure that ncode always gets resolved 
by the linker to the actual address of the function, and not a PLT 
indirection?

Regards

Bryce.