Re: gold regression vs BFD ld: __ehdr_start

[Ian Lance Taylor <iant at google dot com>]

On Sat, Mar 29, 2014 at 6:15 PM, Roland McGrath <roland@hack.frob.com> wrote:
> With trunk on x86_64-linux-gnu:
>
>         $ cat foo.s
>                 .text
>                 .globl _start
>         _start:
>                 lea __ehdr_start(%rip), %r11
>         $ ./gas/as-new -o foo.o foo.s
>         $ ./ld/ld-new -shared -o foo.so foo.o
>         $ readelf -rs foo.so
>
>         There are no relocations in this file.
>
>         Symbol table '.dynsym' contains 6 entries:
>            Num:    Value          Size Type    Bind   Vis      Ndx Name
>              0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
>              1: 00000000000001c1     0 SECTION LOCAL  DEFAULT    4
>              2: 00000000000001c1     0 NOTYPE  GLOBAL DEFAULT    4 _start
>              3: 0000000000200278     0 NOTYPE  GLOBAL DEFAULT    6 __bss_start
>              4: 0000000000200278     0 NOTYPE  GLOBAL DEFAULT    6 _edata
>              5: 0000000000200278     0 NOTYPE  GLOBAL DEFAULT    6 _end
>
>         Symbol table '.symtab' contains 14 entries:
>            Num:    Value          Size Type    Bind   Vis      Ndx Name
>              0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
>              1: 00000000000000e8     0 SECTION LOCAL  DEFAULT    1
>              2: 0000000000000118     0 SECTION LOCAL  DEFAULT    2
>              3: 00000000000001a8     0 SECTION LOCAL  DEFAULT    3
>              4: 00000000000001c1     0 SECTION LOCAL  DEFAULT    4
>              5: 00000000000001c8     0 SECTION LOCAL  DEFAULT    5
>              6: 00000000002001c8     0 SECTION LOCAL  DEFAULT    6
>              7: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT    1 __ehdr_start
>              8: 00000000002001c8     0 OBJECT  LOCAL  DEFAULT    6 _DYNAMIC
>              9: 0000000000000000     0 OBJECT  LOCAL  DEFAULT    6 _GLOBAL_OFFSET_TABLE_
>             10: 00000000000001c1     0 NOTYPE  GLOBAL DEFAULT    4 _start
>             11: 0000000000200278     0 NOTYPE  GLOBAL DEFAULT    6 __bss_start
>             12: 0000000000200278     0 NOTYPE  GLOBAL DEFAULT    6 _edata
>             13: 0000000000200278     0 NOTYPE  GLOBAL DEFAULT    6 _end
>         $ ./gold/ld-new -shared -o foo.so foo.o
>         ./gold/ld-new: error: foo.o: requires dynamic R_X86_64_PC32 reloc against '__ehdr_start' which may overflow at runtime; recompile with -fPIC
>         [Exit 1]
>         $
>
> I think when __ehdr_start was first added to BFD ld, it may have behaved
> this way too.  But it works properly now.  The key issue is that when the
> __ehdr_start symbol is in its indeterminate state, it still needs to be
> understood to be STV_HIDDEN so that it doesn't generate dynamic relocs.
> When it is eventually found that it can be defined and it is--a decision
> that can only be made after layout--then it will be defined as STV_HIDDEN,
> so it should always get static resolution.  If at the end of the way it
> can't be defined (layout with no readable segment covering the file
> headers), then it is probably fine to get an error rather than generating
> the dynamic relocs that would be normal for any random undefined
> symbol--albeit, that is a regression relative to pre-2.23 linkers when
> users happen to use this once mundane, now magic symbol name.  (I'm not
> sure any more if 2.24/trunk BFD ld has that regression against its own
> pre-2.23 behavior or not.)
>
> I think what has to happen is something analogous to what BFD ld does now:
> Add the symbol early on in an undefined or indeterminate state, and then
> define it (or don't) later on.  It's not very clear to me how to do that
> correctly in gold.  It would seem clearest if it can be done in
> define_standard_symbols.  But I don't know what Layout::finalize (where
> it's created now) should do to find it and adjust it to point at the right
> segment.  I also don't know how either case would interact with a user
> defining (in input or script) this symbol name himself, in which case (IIRC
> the BFD ld behavior) the user's symbol should be wholly unmolested (but it
> might be that BFD ld uses the user's value but marks it STV_HIDDEN
> anyway--I'm not sure).

I don't know why __ehdr_start is defined in Layout::finalize.  As you
suggest, it should be defined by define_standard_symbols instead,
setting the only_if_ref field to true.  If necessary, Layout::finalize
can adjust the symbol value using init_output_segment, but only if the
symbol is marked as predefined.  Layout::finalize can simply look up
the symbol by name.

Ian