Re: Reminder: Illegal Package-Private Accesses in libgcj

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

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 
security checks.

Regards

Bryce.