This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch] Update the default ELF linker script to support compact EH

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" <> writes:
> Index: scripttempl/
> ===================================================================
> RCS file: /cvs/src/src/ld/scripttempl/,v
> retrieving revision 1.122
> diff -p -u -r1.122
> --- scripttempl/	28 Apr 2013 14:52:54 -0000	1.122
> +++ scripttempl/	31 May 2013 17:06:41 -0000
> @@ -520,10 +520,11 @@ cat <<EOF
> -  .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
>    /* 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]