Re: [PATCH] [JAVA] Double.parseDouble(null) throw NullPointerException
Hi,
When I use gcj on an RTOS(RTEMS), Double.parseDouble(null) throw
NumberFormatException, but it should throw NullPointerException. So I
add the patch below:
Index: natVMDouble.cc
===
--- natVMDouble.cc (revision 172224)
+++ natVMDouble.cc (working copy)
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
@@ -162,6 +163,9 @@
jdouble
java::lang::VMDouble::parseDouble(jstring str)
{
+ if(str == NULL)
+ throw new NullPointerException();
+
int length = str->length();
while (length > 0
The testsuite/Throw_2.java has been PASS after this patch. what do you
think about this patch?
Thanks,
Jie
Re: [PATCH] [JAVA] Double.parseDouble(null) throw NullPointerException
Hi Tom,
RTEMS does not have virtual memory management, so there is no error
when access the 0 address on rtems.
So 'str->length()' donot throw NPE and just return an meaningless value.
Ps: There is a test:
http://code.google.com/p/rtemsgcj/source/browse/trunk/algorithm/20110810NPE/?r=127,
npe.c is the main file and *.scn is the output.
Thanks,
Jie
2011/8/8 Tom Tromey :
>>>>>> "Jie" == Jie Liu writes:
>
> Jie> + if(str == NULL)
> Jie> + throw new NullPointerException();
> Jie> +
> Jie> int length = str->length();
>
> Why doesn't 'str->length()' throw the NPE?
>
> Tom
>
=== The first mail, for adding Joel ===
Hi,
When I use gcj on an RTOS(RTEMS), Double.parseDouble(null) throw
NumberFormatException, but it should throw NullPointerException. So I
add the patch below:
Index: natVMDouble.cc
===
--- natVMDouble.cc (revision 172224)
+++ natVMDouble.cc (working copy)
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
@@ -162,6 +163,9 @@
jdouble
java::lang::VMDouble::parseDouble(jstring str)
{
+ if(str == NULL)
+ throw new NullPointerException();
+
int length = str->length();
while (length > 0
The testsuite/Throw_2.java has been PASS after this patch. what do you
think about this patch?
Thanks,
Jie
Re: [PATCH] [JAVA] Double.parseDouble(null) throw NullPointerException
2011/8/10 Tom Tromey :
>>>>>> "Jie" == Jie Liu 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
>
[PATCH] [JAVA] patch for Java on RTEMS
Hi, For the previous analysis "libjava patches for RTEMS"[1], there are 6 cases need to pay more attention. PR18699, TLtest, Thread_Interrupt, Thread_Sleep_2, Throw_2 and bclink. After add patch to bdwgc for RTEMS pthread support[2]: PR18699PASS after Modify [A bug in boehm-gc on RTEMS, not related to libjava] TLtestPASS Thread_Interrupt PASS For the other 3 cases: Thread_Sleep_2 PASS [After add patch to rtems] Throw_2 PASS [After add patch to libjava, still need some work][3] bclinkUnSupport [-findirect-dispatch do not support in this case] I think it's time to send out the patch for review, because it may need much time to modify. The patch is attached. How to mark those unsupported cases as expected failures on *-*-rtems* ? [1]http://gcc.gnu.org/ml/java-patches/2011-q3/msg00016.html [2]http://gcc.gnu.org/ml/java-patches/2011-q3/msg00042.html [3]http://gcc.gnu.org/ml/java-patches/2011-q3/msg00037.html Thanks, Jie libjava.patch Description: Binary data
Re: [PATCH] [JAVA] Double.parseDouble(null) throw NullPointerException
> Jie> But it does not work as we want, is there something wrong?
>
> Did you rebuild all of libgcj?
Yes. :)
>
> If you did, then I don't know, you'll have to debug it, sorry.
>
> I vaguely recollect that -fcheck-references adds a check for 'this' at
> the start of final methods. If I'm misremembering, then that is
> probably the problem.
>
The method length() is not a final method, as java/lang/String.java line 447:
public int length()
{
return count;
}
Is this the problem?
Thanks,
Jie
> Tom
>
Re: [PATCH] [JAVA] Double.parseDouble(null) throw NullPointerException
> If you did, then I don't know, you'll have to debug it, sorry. > > I vaguely recollect that -fcheck-references adds a check for 'this' at > the start of final methods. If I'm misremembering, then that is > probably the problem. In my debug, there appears no check for 'this' at start of String.length(): (gdb) s java::lang::VMDouble::parseDouble (str=0x0) at ../../../gcc-trunk/libjava/java/lang/natVMDouble.cc:165 165 int length = str->length(); (gdb) s java.lang.String.length()int (this=@336e44) at /mnt/gcj/gcj-rtems-work/gcc-trunk/libjava/java/lang/String.java:451 451 return count; (gdb) p count $5 = -268370093 (gdb) p this $6 = (java.lang.String *) 0x0 Thanks, Jie
Re: [PATCH] [JAVA] patch for Java on RTEMS
Hi, I have add the boehm-gc patch and the configure for gcc patch to the patch attached. So we can add this patch and then compile gcj for RTEMS. Best Regards, Jie gcj-rtems.patch Description: Binary data
Re: [PATCH] [JAVA] patch for Java on RTEMS
> Looks OK, but there is no ChangeLog. Do you have copyright > assignment? Have added ChangeLog to the patch, please see the attachment. And I think I have copyright assignment, because I have Free Software Foundation paperwork, as "ASSIGNMENT - GNU GCC ... JIE RT688742" Best Regards, Jie gcj-rtems.patch Description: Binary data
Have a boehm-gc patch for gcj/rtems
Hi, I am working on porting gcj to rtems now, it's a project of GSoC2011.[1] And now, the first step: boehm-gc have been ported, so I want to get this patch reviewed and merged. And I have filed the FSF Paperwork, the patch has been attached. Thank you for your time. Best Regards, Jie [1]http://socghop.appspot.com/gsoc/org/google/gsoc2011/rtems boehm-gc.diff Description: Binary data
Re: Have a boehm-gc patch for gcj/rtems
Hi,
Java HelloWorld compiled by cross gcj for RTEMS can run without
problem now, I think it's time for get the boehm-gc patch reviewed and
merged. :) Here is the patch:
Index: mach_dep.c
===
--- mach_dep.c (revision 172224)
+++ mach_dep.c (working copy)
@@ -411,7 +411,8 @@
word dummy;
# if defined(USE_GENERIC_PUSH_REGS)
-# ifdef HAVE_BUILTIN_UNWIND_INIT
+# if defined(HAVE_BUILTIN_UNWIND_INIT)\
+ &&!(defined(I386) && defined(RTEMS))
/* This was suggested by Richard Henderson as the way to */
/* force callee-save registers and register windows onto */
/* the stack. */
@@ -437,8 +438,8 @@
for (; (char *)i < lim; i++) {
*i = 0;
}
-# if defined(MSWIN32) || defined(MSWINCE) \
- || defined(UTS4) || defined(LINUX) || defined(EWS4800)
+# if defined(MSWIN32) || defined(MSWINCE) || defined(UTS4) \
+ || defined(LINUX) || defined(EWS4800) || defined(RTEMS)
(void) setjmp(regs);
# else
(void) _setjmp(regs);
Index: include/private/gcconfig.h
===
--- include/private/gcconfig.h (revision 172224)
+++ include/private/gcconfig.h (working copy)
@@ -315,6 +315,11 @@
#define mach_type_known
# endif
# endif
+# if defined(__rtems__) && (defined(i386) || defined(__i386__))
+# define I386
+# define RTEMS
+# define mach_type_known
+# endif
# if defined(NeXT) && defined(mc68000)
# define M68K
# define NEXT
@@ -1297,6 +1302,17 @@
# define STACKBOTTOM ((ptr_t)0xc000)
# define DATAEND /* not needed */
# endif
+# ifdef RTEMS
+# define OS_TYPE "RTEMS"
+# include
+extern int etext[];
+extern int end[];
+void *rtems_get_stack_bottom();
+# define InitStackBottom rtems_get_stack_bottom()
+# define DATASTART ((ptr_t)etext)
+# define DATAEND ((ptr_t)end)
+# define STACKBOTTOM ((ptr_t)InitStackBottom)
+# endif
# ifdef DOS4GW
# define OS_TYPE "DOS4GW"
extern long __nullarea;
@@ -2370,7 +2386,8 @@
# else
# if defined(NEXT) || defined(DOS4GW) || \
(defined(AMIGA) && !defined(GC_AMIGA_FASTALLOC)) || \
-(defined(SUNOS5) && !defined(USE_MMAP))
+(defined(SUNOS5) && !defined(USE_MMAP)) || \
+ defined(RTEMS)
# define GET_MEM(bytes) HBLKPTR((size_t) \
calloc(1, (size_t)bytes
+ GC_page_size) \
+ GC_page_size-1)
Index: configure
===
--- configure (revision 172224)
+++ configure (working copy)
@@ -14867,6 +14867,8 @@
$as_echo "#define _REENTRANT 1" >>confdefs.h
;;
+ rtems)
+;;
decosf1 | irix | mach | os2 | dce | vxworks)
as_fn_error "thread package $THREADS not yet supported" "$LINENO" 5
;;
Index: os_dep.c
===
--- os_dep.c(revision 172224)
+++ os_dep.c(working copy)
@@ -1507,7 +1507,7 @@
# if !defined(OS2) && !defined(PCR) && !defined(AMIGA) \
&& !defined(MSWIN32) && !defined(MSWINCE) \
- && !defined(MACOS) && !defined(DOS4GW)
+ && !defined(MACOS) && !defined(DOS4GW) && !defined(RTEMS)
# ifdef SUNOS4
extern caddr_t sbrk();
Best Regards,
Jie
2011/6/4 Jie Liu :
> Hi,
>
> I am working on porting gcj to rtems now, it's a project of GSoC2011.[1]
> And now, the first step: boehm-gc have been ported, so I want to get
> this patch reviewed and merged.
>
> And I have filed the FSF Paperwork, the patch has been attached.
> Thank you for your time.
>
> Best Regards,
> Jie
>
> [1]http://socghop.appspot.com/gsoc/org/google/gsoc2011/rtems
>
libjava patches for RTEMS
Hi, GCJ is available on RTEMS/pc386. Here is the libjava testsuite result on RTEMS/pc386: === libjava Summary === # of expected passes2249 # of unexpected failures94 # of untested testcases 66 As the testsuite result is good enough, I think it's time to get the patch reviewed and merged into gcc. The patch is attached. :) Best Regards, Jie libjava.patch Description: Binary data
