[Patch] Update the default ELF linker script to support compact EH
Richard Sandiford
rdsandiford@googlemail.com
Sat Jun 1 08:07:00 GMT 2013
BTW, a question about the spec. On page 30 it says:
----------------------------------------------------------------------------
12.3 LD
• The scripts will need augmenting to place the .eh_frame_hdr and
.gnu_extab sections.
• The linker will need augmenting to sort the .eh_frame_hdr input sections,
attach a compact EH Frame Header and define the __GNU_EH_FRAME_HDR symbol.
• The linker will need augmenting to process R_MIPS_EH relocations.
• It should be an error to encounter .eh_frame_hdr input sections without
having specified the –eh-frame-hdr option.
----------------------------------------------------------------------------
Do points 2 and 4 mean ".eh_frame_entry input section" rather than
".eh_frame_hdr input section"?
"Moore, Catherine" <Catherine_Moore@mentor.com> writes:
> Index: scripttempl/elf.sc
> ===================================================================
> RCS file: /cvs/src/src/ld/scripttempl/elf.sc,v
> retrieving revision 1.122
> diff -p -u -r1.122 elf.sc
> --- scripttempl/elf.sc 28 Apr 2013 14:52:54 -0000 1.122
> +++ scripttempl/elf.sc 31 May 2013 17:06:41 -0000
> @@ -520,10 +520,11 @@ cat <<EOF
> ${CREATE_SHLIB-${SDATA2}}
> ${CREATE_SHLIB-${SBSS2}}
> ${OTHER_READONLY_SECTIONS}
> - .eh_frame_hdr : { *(.eh_frame_hdr) }
> - .eh_frame ${RELOCATING-0} : ONLY_IF_RO { KEEP (*(.eh_frame)) }
> + .eh_frame_hdr : { *(.eh_frame_hdr) ${RELOCATING+*(.eh_frame_entry .eh_frame_entry.*)} }
> + .eh_frame ${RELOCATING-0} : ONLY_IF_RO { KEEP (*(.eh_frame)) ${RELOCATING+*(.eh_frame.*)} }
If I understand the spec correctly, the .eh_frame.* sections are still
just used for the "legacy" DWARF encoding. Is that right? If so, this
patch seems to be doing two things: extending the set of input sections
that can be used for DWARF unwind info, and adding new sections for the
new scheme. I think the two should be separated, and I'd prefer to leave
the .eh_frame.* part until the patch that shows how it should be used.
How do the new sections work with --gc-sections? We need the KEEP for
.eh_frame because there are no direct references to input CIEs and FDEs,
The linker then removes information for functions are that not linked.
Don't the input .eh_frame_entry sections need a KEEP in the same way?
Nothing in the input objects refers to the .eh_frame_entry data
directly AIUI.
Also, the section globs for .eh_frame_entry and .gnu_extab are inconsistent.
The .eh_frame_entry version disallows things like .eh_frame_entry1234, whereas:
> .gcc_except_table ${RELOCATING-0} : ONLY_IF_RO { *(.gcc_except_table
> .gcc_except_table.*) }
> + .gnu_extab ${RELOCATING-0} : ONLY_IF_RO { *(.gnu_extab*) }
> /* These sections are generated by the Sun/Oracle C++ compiler. */
> .exception_ranges ${RELOCATING-0} : ONLY_IF_RO { *(.exception_ranges
> .exception_ranges*) }
allows .gnu_extab1234. The .eh_frame_entry way seems better, so would
".gnu_extab .gnu_extab.*" be OK? Either way:
> @@ -535,7 +536,8 @@ cat <<EOF
> ${CREATE_PIE+${RELOCATING+. = ${SHLIB_DATA_ADDR-${DATA_SEGMENT_ALIGN}};}}
>
> /* Exception handling */
> - .eh_frame ${RELOCATING-0} : ONLY_IF_RW { KEEP (*(.eh_frame)) }
> + .eh_frame ${RELOCATING-0} : ONLY_IF_RW { KEEP (*(.eh_frame)) ${RELOCATING+*(.eh_frame.*)} }
> + .gnu_extab ${RELOCATING-0} : ONLY_IF_RW { *(.gnu_extab) }
I assume this .gnu_extab needs a glob of some kind too.
Thanks,
Richard
More information about the Binutils
mailing list