Re: gcj executable size reduction?

[Jeff Sturm <jsturm at one-point dot com>]

On Mon, 19 Apr 2004, Bryce McKinlay wrote:
> Boehm, Hans wrote:
>
> >There's a related problem, which is on my to-do list for the garbage collector.
> >It appears that at least for X86 Linux, exception range tables end up in
> >a writable data segment.
> >
>
> Unfortunately, the otherwise static and read-only DWARF2 EH info
> contains a reference to the global function __gcj_personality_v0 in
> every CIE entry. That requires a runtime relocation so its probably why
> the EH info ends up in a writable section.

Unless I am mistaken, in recent gcc builds .eh_frame *is* mapped to a
readonly segment.  The personality routine uses a pcrel encoding which
does not need relocation.

Look at gcj output with -fPIC:

        .section        .eh_frame,"a",@progbits
	...
        .byte   0x9b    # Personality (indirect pcrel sdata4)
        .long   DW.ref.__gcj_personality_v0-.

This references the hidden symbol:

        .hidden DW.ref.__gcj_personality_v0
        .weak   DW.ref.__gcj_personality_v0
        .section
.gnu.linkonce.d.DW.ref.__gcj_personality_v0,"aw",@progbi        .align 4
        .type   DW.ref.__gcj_personality_v0, @object
        .size   DW.ref.__gcj_personality_v0, 4
DW.ref.__gcj_personality_v0:
        .long   __gcj_personality_v0

This is the real function pointer, mapped to a writable segment.  However
there is at most one instance of this per DSO, shared by all CIEs.

Jeff