More questions about _GLOBAL

[Bryce McKinlay]

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.

regards

Bryce.