This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: GCJ on arm-linux
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.