gold regression vs BFD ld: __ehdr_start

[Roland McGrath <roland@hack.frob.com>]

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).

This is yet another time I've wished we had a common test suite for both
linkers to verify matching behavior.  Of course I understand why output
doesn't match byte-for-byte and why the whole style of the existing ld
testsuite doesn't mesh well with a more semantically-precise testing
methodology.  But still, harumph.


Thanks,
Roland