Re: Reminder: Illegal Package-Private Accesses in libgcj

[Andrew Haley <aph at redhat dot com>]

Bryce McKinlay writes:
 > On Nov 4, 2003, at 12:44 AM, Andrew Haley wrote:
 > 
 > > 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. 

Okay.

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

Oh, right.  No argument there.  I was totally confused because it
sounded like you were changing the way it works, when what you were
proposing to do was essentially the same as we do already.  So I was
confused...

Andrew.