GCJ on arm-linux

Thu Aug 10 08:48:00 GMT 2006

Casey Marshall writes:
 > Andrew Haley wrote:
 > > Casey Marshall writes:
 > > > 
 > > > I'm looking into running GCJ on an arm-linux system, and from some
 > > > searching it looks as though we do not yet have full support for this
 > > > platform. Is this right?
 > > > 
 > > > My understanding is that some of the hairy bits for handling null
 > > > dereferences, and libffi, are currently missing. Is there anything else
 > > > missing?
 > > > 
 > > > How should I go about determining what's missing, and what is
 > > > necessary to implement proper arm-linux support? This stuff feels
 > > > under-documented.
 > > 
 > > Yeah, we haven't documented what we haven't done. :-)
 > 
 > Or, uh, what you have.
 > 
 > > I think we're missing the signal handler and libffi invocation
 > > interface. 
 > > 
 > > Signal handlers are simpler than they used to be, for sure. We'd need
 > > MD_FALLBACK_FRAME_STATE_FOR.
 > 
 > This I was aware of (and the replies confirmed it). What does this do? I
 > understand what FFI needs to do, but this is really opaque.
When the kernel saves the user space registers on a trap, it stashes
them in the user space stack. When unwinding, we need to read the
register state from the structure the kernel put on the stack. That
way, we unwind through a signal.
I must also point out that this isn't absolutely necessary -- it's a
performance improvement over null pointer checks.
 > > Where this starts to get rather weird is ARM using non-DWARF unwinder
 > > data. I don't know if the ARM unwinder data on your system is DWARF
 > > or not; I don't know if ARM unwinder data is suitable for the things
 > > we need to do in Java.
 > > 
 > 
 > That's a good thing to look out for, thanks for mentioning that.
 > 
 > > But it's easy enought to find out all the answers we need by asking
 > > the right people.
 > > 
 > 
 > I'll try to get someone with a deeper understanding of ARM to look at
 > this on my side.
Try Richard Earnshaw <rearnsha@arm.com>
Andrew.