jdk15/javaws on amd64

[Peter Jeremy]

On Mon, Mar 17, 2008 at 06:31:44AM -0700, Greg Lewis wrote:
>On Mon, Mar 17, 2008 at 09:30:54AM +1100, Peter Jeremy wrote:
>>  75310 java     CALL  stat(0x7fffffffd250,0x7fffffffd6f0)
>>  75310 java     NAMI  "<8B>H<83>[]?1?H<83>[]?AUATUSH<83>H<89>?H<8B>^E?^M^R/deploy.jar"
>>  75310 java     RET   stat -1 errno 2 No such file or directory
>
>That certainly is an interesting path for deploy.jar...
>
>The path to deploy.jar is set up in deploy/src/javaws/share/native/launcher.c,
>so thats probably a good place to start.

I've done some poking at it with both some printf()s and gdb and it
appears to be a gcc bug - in fact, I'm surprised it works at all...

The relevant function is GetBootClassPath():
char* GetBootClassPath(void) {
  static char bootclasspath[MAXPATHLEN];
#ifdef _DEBUG
  sprintf(bootclasspath, "%s%c%s%c%s%c%s", 
                sysGetJarLib(), FILE_SEPARATOR, "javaws_g.jar",
                PATH_SEPARATOR, sysGetJarLib(), FILE_SEPARATOR, "deploy_g.jar");
#else
  sprintf(bootclasspath, "%s%c%s%c%s%c%s", 
                sysGetJarLib(), FILE_SEPARATOR, "javaws.jar",
                PATH_SEPARATOR, sysGetJarLib(), FILE_SEPARATOR, "deploy.jar");
#endif
  return bootclasspath;
}

Within the jdk build, launcher.c is compiled with:
/usr/bin/gcc  -I../../src/javaws/share/native -I../../src/javaws/solaris/native -I../../src/javaws/share/native/jpeg -I/home/obj/usr/ports/java/jdk15/work/control/build/bsd-amd64/tmp/deploy/javaws/jawsgensrc/headers -I/usr/local/include -I/usr/local/include -D_ALLBSD_SOURCE  ../../src/javaws/share/native/launcher.c -c -o /home/obj/usr/ports/java/jdk15/work/control/build/bsd-amd64/tmp/deploy/javaws/jawsobj/launcher.o

The second sysGetJarLib() is passed to sprintf() as the first memory
operand (ie (%rsp)) but for reasons known best to gcc, only a 32-bit
move is used, leaving the high 32-bits alone.  In my case, when
sprintf() accesses the 64-bit value it winds up with an arbitrary address
inside one of the dynamic libraries.

I've tried building a simple test using:
cc -O2 -fno-strict-aliasing -pipe -march=nocona  -DDMEM  foo.c  -o foo
and the code is compiled correctly (actually, the generated code is
basically identical except it correctly uses 64-bit moves).  I'm still
investigating what has gone wrong.

Out of interest, why isn't jdk15 being built using the default CFLAGS?

-- 
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-java/attachments/20080318/98f5217d/attachment.pgp