More questions about _GLOBAL
Tue Jan 29 13:55:00 GMT 2002
Adam Megacz wrote:
>>I can only speak for ELF systems, in which case a list of pointers to
>>these functions is placed in a special section, and the linker pulls
>>them together into one list which is traversed at program startup.
>So the GNU ld knows that .jcr is a "magic" section which should
>recieve special handling?
Its actually handled by the crtstuff in libgcc. libgcc checks for the
symbol _Jv_RegisterClasses and if present calls it for any .jcr sections.
>>Hmm... I'm not sure I understand what you're asking. You need these
>>_GLOBAL__ functions to implement static initializers.
>Ugh, so _Jv_RegisterClass calls class initializers (<clinit>'s)?
No. Think of _Jv_RegisterClass(es) as the bootstrapping mechanism which
tells the Java runtime that the class exists. Each time a new binary
object gets loaded (either before main() is called or when a shared
library gets dlopen()ed), _Jv_RegisterClass(es) gets called
automatically for each java class in that object. The classloader can
then add it to its class list and things like Class.forName() will be
able to find it.
>The optimization I'm trying to do is this: if none of a class's
>constructors are reachable, I prune foo.bar.baz.class$ from the
>output. Unfortunately, the __GLOBAL_foo.bar.baz symbol will call
>_Jv_RegisterClass(foo.bar.baz.class$), which then SEGV's.
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. Another
solution would be to change _Jv_RegisterClass() to ignore a NULL
argument, but I'd be hesitant to do that since it could hide bugs.
More information about the Java