More questions about _GLOBAL

[Adam Megacz]

Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:
> In that case it should be fine to remove the __GLOBAL_foo.bar.baz. There 
> is no point registering a class which does not exist, after all.

Yeah, the unfortunate problem is that if two classes are in the same
compilation unit (example: java.lang.CPlusPlusDemangler and
java.lang.Throwable), they share a __GLOBAL_ symbol. Figuring out who
shares with who (in case a class I need shares a __GLOBAL_ with a
class I don't need) is near-impossible.


> Another solution would be to change _Jv_RegisterClass() to ignore a
> NULL argument,

Tried that too, unfortunately strip and ld don't work the way I think
they should. The address of the class$ symbol is inserted into the
__GLOBAL_ symbol using a file-local symbol relocation. When I strip
that symbol before linking, or if I remove the section, strip/ld seems
to randomly pick another symbol to use, instead of writing a 0x0.

Here's an example that I posted to the binutils mailing list:

megacz@curry$ /usr/local/gcc/bin/i686-pc-mingw32-strip -g libgcj.a
megacz@curry$ /usr/local/gcc/bin/i686-pc-mingw32-objdump -r libgcj.a | grep -A4 \\[.text\$_GLOBAL__I__ZN4java2io19SyncFailedExceptionC1Ev
RELOCATION RECORDS FOR [.text$_GLOBAL__I__ZN4java2io19SyncFailedExceptionC1Ev]:
OFFSET   TYPE              VALUE
00000009 dir32             .data$_ZN4java2io19SyncFailedException6class$E
0000000e DISP32            __Jv_RegisterClass

megacz@curry$ /usr/local/gcc/bin/i686-pc-mingw32-strip -gN .data\$_ZN4java2io19SyncFailedException6class\$E libgcj.a
megacz@curry$ /usr/local/gcc/bin/i686-pc-mingw32-objdump -r libgcj.a | grep -A4 \\[.text\$_GLOBAL__I__ZN4java2io19SyncFailedExceptionC1Ev
RELOCATION RECORDS FOR [.text$_GLOBAL__I__ZN4java2io19SyncFailedExceptionC1Ev]:
OFFSET   TYPE              VALUE
00000009 dir32             __ZN4java2io19SyncFailedExceptionC1Ev
0000000e DISP32            __Jv_RegisterClass

....

Any other ideas for how to accomplish what I'm trying to do are
welcome; this one really has me stumped.

Right now I have _Jv_RegisterClass return early if (klass->state !=
JV_STATE_NOTHING), but that's very, very unreliable and clearly not an
acceptable long-term solution.

  - a