2011/8/10 Tom Tromey <tro...@redhat.com>:
>>>>>> "Jie" == Jie Liu <lj8...@gmail.com> writes:
>
> Jie> RTEMS does not have virtual memory management, so there is no error
> Jie> when access the 0 address on rtems.
> Jie> So 'str->length()' donot throw NPE and just return an meaningless value.
>
> If you compile the Java parts of the library with -fcheck-references, it
> should work. This is something you have to set up as part of the port,
> as it is decided at (libgcj-) configure time.
>
Thank you very much for the information you provide. :)
I add the following patch for -fcheck-references:
Index: configure.host
===================================================================
--- configure.host (revision 172224)
+++ configure.host (working copy)
@@ -347,8 +347,14 @@
slow_pthread_self=
can_unwind_signal=yes
;;
+ *-*-rtems*)
+ can_unwind_signal=no
+ CHECKREFSPEC=-fcheck-references
+ DIVIDESPEC=-fuse-divide-subroutine
+ ;;
esac
+
case "${host}" in
*-cygwin* | *-mingw*)
fallback_backtrace_h=sysdep/i386/backtrace.h
And we can see the following have -fcheck-references:
/mnt/gcj/mytoolchain/libexec/gcc/i386-rtems/4.7.0/jc1
/tmp/ccYuDgD5.jar -fsource-filename=HelloWorld.java
-fhash-synchronization -fuse-divide-subroutine -fcheck-references
-fuse-boehm-gc -fkeep-inline-functions -quiet -dumpbase
HelloWorld.java -mtune=i386 -march=i386 -auxbase HelloWorld -g -g
-Wall -version -fsaw-java-file
-fbootclasspath=./:/usr/share/java/ecj.jar:/mnt/gcj/mytoolchain/share/java/libgcj-4.7.0.jar
-faux-classpath /tmp/cc6nFx0I.zip -o /tmp/ccCuf7ju.s
GNU Java (GCC) version 4.7.0 20110409 (experimental) (i386-rtems)
But it does not work as we want, is there something wrong?
Thanks,
Jie
> This won't help with the native code. IIRC in the end we just gave up
> on that; if you wanted real correctness you would have to add a null
> check at every dereference in the C++ code. I believe Andrew had a g++
> patch to do this in the compiler, but it was rejected.
>
> Tom
>
