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]

GCJ and embedded M68k problems/questions


I have been recently porting the CVS version of libgcj to an embedded
68040/68360 environment using a m68k-coff cross compiler and have the
following questions/problems. I was hoping somebody would be able to help.

1.  Java exceptions were not working.  I have not been able to get dwarf
exceptions to work, however have been able to get the long jump exceptions
working.  The problem with the long jump exceptions was an inconsistency
when generating the LSDA header in expect.c.  An alignment of 4 is assumed
when generating the offset lengths however the m68k coff code generation was
generating an ".even" which only aligns to an even boundary.  As I'm using
gas, I modified the output to be .p2align 2 which solved the problem.  I
tried .align 4 but this did not seem to do as I expected (or as was
indicated in the manual).  Has .align changed, I am using gas v 2.13.1.  Has
anybody else had problems with java exceptions on the 68K?

2.   During the 3.4 initialization, I was getting a null pointer in
natClassLoader FindClass().  There was an attempt to use system class loader
to load "java.lang.Object" however the system class loader had not be
initialized yet.  As my image is statically linked and java.lang.Object was
a precompiled  I modified natClassLoader _Jv_PrepareCompiledClass to
register class into the class cache which fixed the problem.  This problem
did not exist in gcc 3.3.  The question is how are precompliled classes
usually registered so that there is not need to invoke the loader to load
them.  Am I missing part of the initialization sequence, I run the program
via JvRunMain.

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

4.  make install installs the generated java header files into
$PREFIX/include rather than the more usual $PREFIX/$TARGET/include.  This is
not really a problem except that the current implementation copies some java
files (like ConcreteProcess.java) depending on the target platform,
resulting in minor but important differences on the java header files.  This
causes problems when more than one target is generated.  I generate
compilers for cygwin, linux, solaris as well as powerpc and m68k
environments.  Furthermore, when generating with the multilib options the
same files are copied into the same location for each of the multilibs which
is a bit inefficient.  Would it be possible to ensure that the generated
java Java header files are the same for each java files and only copying the
files once, by for example making each variation have the same native
methods and implement dummy functions in the corresponding c++ files?

Thanks in advance
John 



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