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 and embedded M68k problems/questions


>>>>> "John" == John Neil <jneil@atrove.com> writes:

John> Has anybody else had problems with java exceptions on the 68K?

I'm not sure anybody else has built gcj with a 68k target.  Maybe
Anthony?  Anyway, this sounds like something to talk to the 68k port
maintainer about -- it probably isn't java-specific.  Do C++
exceptions work for you?

John> The question is how are
John> precompliled classes usually registered so that there is not
John> need to invoke the loader to load them.  Am I missing part of
John> the initialization sequence, I run the program via JvRunMain.

Take a look at gcc/java/class.c:emit_register_classes().
In general we prefer to emit a .jcr section that lists all compiled
classes.  Then crt0.o (I think) ensures that these are registered
with the runtime.

In the libgcj runtime this means a call to _Jv_RegisterClasses().
Set a breakpoint there to see if the classes are being registered.

John> 3.  I get a null pointer in System during initialization as to
John> tries to set the property java.io.tmpdir from java.tmpdir which
John> has not been initialized as I have no file system.

That looks like mildly bogus code in System to me.  I'm willing to
remove it, if the Classpath folks agree.  Want to send a patch?

But your port should probably set java.io.tmpdir anyway, even to
something bogus.  What "OS flavor" are you using?  E.g., where does
platform.h point?

John> 4.  make install installs the generated java header files into
John> $PREFIX/include rather than the more usual
John> $PREFIX/$TARGET/include.

There's other complaints about similar things.  I have been studiously
avoiding the subject.  It does seem like installing in a per-platform
directory would be simplest.

John> Would it be possible to ensure that the generated java Java
John> header files are the same for each java files and only copying
John> the files once, by for example making each variation have the
John> same native methods and implement dummy functions in the
John> corresponding c++ files?

There might be cases where we don't want to do this.  E.g., AWT peers.

Tom


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