why does .jcr work?

Wed Nov 6 12:00:00 GMT 2002

Adam Megacz writes:
 > 
 > Each class has a .jcr section containing its class registration. On
 > startup, libgcc's crtstuff.o looks for the symbol __JCR_BEGIN__ and
 > scans from there until __JCR_END__ to find the class registrations.
 > 
 > Two questions:
 > 
 > 1. Why are all the .jcr sections guaranteed to be adjacent in the
 > linked binary? Does the linker guarantee alphabetical ordering, or
 > is ".jcr" a "magic section" that gets special treatment from the
 > linker?
Whenever you want to understand linker magic, use the command
gcj foo.java bar.java bloop.java -Wl,--verbose
In this case you'll see:
GNU ld version 2.13
 Supported emulations:
 elf_i386
 i386linux
using internal linker script:
==================================================
/* Script for -z combreloc: combine and sort reloc sections */
OUTPUT_FORMAT("elf32-i386", "elf32-i386",
 "elf32-i386")
OUTPUT_ARCH(i386)
ENTRY(_start)
SEARCH_DIR("/usr/share/gnu/i686-pc-linux-gnu/lib"); SEARCH_DIR("/usr/share/gnu/lib"); SEARCH_DIR("/usr/local/lib"); SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib");
/* Do we need any of these for elf?
 __DYNAMIC = 0; */
SECTIONS
{
... and later ...
 
 .jcr : { KEEP (*(.jcr)) }
So yeah, the linker is treating ".jcr" specially.
 > 2. Why is this in libgcc instead of simply in the constructor for some
 > static C++ class in libgcj?
What problem would that solve?
Andrew.