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: gcj-security and some issues


Andrew Haley wrote:

> >It would be interesting if
> >the compiler could put the start and the end adress (pc) (perhaps
> >relative adress, for relocation and so on) of the methods that were
> >written in java in a write protected memory area (in the constant
> >region).
> > The compiler already does this, as part of the DWARF2 unwind info. The > tricky part is mapping the function to the class it belongs to. > Currently this is done with a hash table but possibly we can add > something to the FDE (LDSA?) to make it more efficient.


The unwinder uses a binary search on each PC value in a stack frame to
locate the start of the function. Going from there to a class is a
relatively small thing.



Well, you'd think so, but this is the reason why my patch is taking so long - it becomes complicated because of the Linker/PLT messing function pointers up. Besides that, it takes a reasonable amount of code (potentially during startup if a stack trace is needed) and a not insignificant amount of locking and memory use to build up the hash table that is used to do this mapping.


So, I had the idea to actually put a link to the class associated with a given frame into the unwind info somehow. I'm guessing thats probably fairly complicated to do, though, so it won't be in the initial patch.

We already have everything needed to make this work. As I understand
it, your new stack trace infrastructure will make this cleaner, but
will probably have little impact on performance, either positive or
negative. From the point of view of the user, it's a change of
interface.



Yes, thats right.


Regards

Bryce


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