jdk15/javaws on amd64

[Greg Lewis]

G'day Peter,

On Tue, Mar 18, 2008 at 05:15:25PM +1100, Peter Jeremy wrote:
> 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.

Saw your later posting about it being the prototype for sysGetjarLib.

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

This isn't deliberate.  Its just likely that we haven't caught all the
places compile flags are set or overridden and made sure it respects
CFLAGS.

-- 
Greg Lewis                          Email   : glewis at eyesbeyond.com
Eyes Beyond                         Web     : http://www.eyesbeyond.com
Information Technology              FreeBSD : glewis at FreeBSD.org