This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
why does .jcr work?
- From: Andrew Haley <aph at redhat dot com>
- To: Adam Megacz <adam at megacz dot com>
- Cc: java at gcc dot gnu dot org
- Date: Wed, 6 Nov 2002 19:48:36 +0000 (GMT)
- Subject: why does .jcr work?
- References: <867kfq4hkw.fsf@nowhere.com>
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.