gcj executable size reduction?

Tue Apr 20 01:50:00 GMT 2004

On 2004年4月19日, 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