Hi, I'd be inclined to have a look at the code produced with and without the workaround. The easiest way I find to do this is to temporarily hack the Makefile and add a -S onto the CFLAGS. Touch the file and remake, leaving the assembler in the .o file (of course the link will now fail). This way you don't have to worry about include paths, -Ds, etc.
Alternatively you can get a dissassembly in gdb with x/i local_bind... Rob. P.S. What version of JamVM were you using? I kinda get worried when I see pointers changing, as the CVS version updates pointers (heap compaction) but this isn't an object reference... On 4/14/06, Casey Marshall <[EMAIL PROTECTED]> wrote: > On Apr 13, 2006, at 5:48 PM, Tom Tromey wrote: > > >>>>>> "Casey" == Casey Marshall <[EMAIL PROTECTED]> writes: > > > > Casey> This isn't really related, but compiling this code with GCC > > 4.0.1 on > > Casey> Darwin/x86 introduces a potentially serious problem. In the > > Casey> `localBind' JNI function, I am doing this: > > > > Casey> So, my question is, is this a known problem with GCC? If so, > > is there > > Casey> any way to work around it? > > > > Whenever I see a cast these days, I think that there must be an > > aliasing bug. But if there's one in this code, I don't see it. > > Offhand I don't recall hearing of a bug like this. > > > > The cast got me thinking, because GetStringUTFChars returns `const > char *', and I'm trying to keep the code -Werror clean, so I cast it > to `char *'. Changing everything to `const char *' in both the JNI > function and the `local_bind' function does nothing, though. > > My workaround so far is to add this to `local_bind': > > > static int foo = 0; > > ... > > if (foo) > > fprintf (stderr, "bind %p\n", addr); > >
