Re: gold regression vs BFD ld: __ehdr_start

[Roland McGrath <mcgrathr at google dot com>]

On Tue, Apr 1, 2014 at 2:50 PM, Cary Coutant <ccoutant@google.com> wrote:
> Those test cases use a linker script with a SECTIONS clause and no
> PHDRS clause. In this case, gold runs define_standard_symbols before
> any segments have been created at all. As a result, all the standard
> symbols that get added are added as constants, and that failed my
> assert in set_output_segment(). I can relax that assert, but I've got
> to wonder if we're doing the right thing here with any of the other
> standard symbols -- it seems to me they'll all get set incorrectly.

Certainly worth worrying about.  I've definitely seen cases in the past
where gold did not implement linker script semantics properly.
(https://sourceware.org/bugzilla/show_bug.cgi?id=13163 comes to mind.)

> In ld/testsuite, the ehdr_start_missing.t script attempts to construct
> a situation where the first load segment cannot contain the headers by
> setting the text section start address to 0x10000000. That doesn't
> work! (At least, not in gold.) Gold will happily place the headers at
> 0x10000000, and place the text section immediately after that. I'm not
> sure if this is a bug or a feature. I think this is a known difference
> between the two linkers that has been discussed before.

It's a bug.  The linker script said where the .text section should be, and
you placed the .text section someplace else.  I was not aware of this
particular "difference" before.  It feels similar to two issues I am aware
of:

* gold's -Ttext=x means -Ttext-segment=x, whereas -Ttext=x is supposed to
  mean --section-start=.text=x and that (like the linker script case above)
  does not give the linker license to actually place .text at x+SIZEOF_HEADERS.
* https://sourceware.org/bugzilla/show_bug.cgi?id=13163c#5 points out out a
  case where assignment of . to a constant means something different in
  gold (I think it acts as relative to some section rather than absolute,
  but I no longer recall the exact details).

> The only way to keep the headers out of the first load segment is to
> set the text segment at an address that is not a multiple of the page
> size. For example, if I run with -Ttext=0x1000100, I'll get the
> expected undefined reference error.

That's a fine thing to test, too.  For gold it certainly makes sense to
exercise cases without linker scripts, since the internal logic is so
different for with vs without.  But getting that case right is not really
sufficient to declare __ehdr_start properly supported.

> Unfortunately, even if the reference is weak, we always get an error.
> By defining the symbol early, it's overriding the symbol's binding
> with STB_GLOBAL, so by the time we try to apply the relocation, we've
> lost track of the weak binding.

That's certainly a bug.  I don't know how to address it.  I had hoped that
the 'only_if_ref' flag would have the semantics that if there was another
definition, none of the symbol details in the call would modify it.  But I
can imagine why it's not like that.

The -shared case working right without trying to generate a dynamic reloc
is sufficient for gold to pass glibc's configure check for __ehdr_start
support and for __ehdr_start as used in ld.so to be correct.  So perhaps
what you've got now is enough better to be worth putting in.

The other corner cases are of some interest to me, but I don't think
anything I'm actually planning to do will wind up exercising them.


Thanks,
Roland