Reminder: Illegal Package-Private Accesses in libgcj
Mon Nov 3 22:18:00 GMT 2003
On Nov 4, 2003, at 12:44 AM, Andrew Haley wrote:
> It's clearly better to use the reflection data to do this job. Note
> that the *only* reason I didn't throw away all the business of calling
> an external addr2line a long while ago is that people were (and
> presumably still are) keen on getting line numbers in stack traces.
Right, I'm keeping the addr2line wrapper around for just this purpose -
getting the line numbers for printStackTrace()/getStackTrace(). Its
quite slow unfortunately - there's a noticeable pause while addr2line
opens up our 40MB+ shared library. But for stack traces, that probably
isn't a huge problem.
> The existing code used for walking the stack to get a security context
> already does what you're suggesting -- it generates a hash table of
> ncode values and uses it to find the class of a call frame. The only
> case in which this fails to work is where a method is defined in a
> compilation unit other than that of the class to which it belongs, and
> the only time that happens is in native code.
It also fails where the main program calls a non-virtual method in
libgcj directly, due to the PLT issue I mentioned in an earlier email.
But Richard suggested a solution for that which should work nicely
(also the BC-ABI, when complete, shouldn't have the problem). Actually
it seems to work fine for native CNI methods, so long as their ncode
values arn't PLT entries. I guess we'll need some special handling for
the JNI case.
> So, what are you proposing to do that's really different? Please
> explain, and let us discuss the implications before we go any further.
I'm just proposing to clean it all up. Do what we do now in a more sane
way. Avoid the needless allocations, complicated system of passing
around arrays of RawDatas, etc, and provide a nice native interface for
More information about the Java