This is the mail archive of the
mailing list for the binutils project.
Re: gold regression vs BFD ld: __ehdr_start
- From: Roland McGrath <mcgrathr at google dot com>
- To: Cary Coutant <ccoutant at google dot com>
- Cc: Ian Lance Taylor <iant at google dot com>, Binutils <binutils at sourceware dot org>
- Date: Tue, 1 Apr 2014 15:50:11 -0700
- Subject: Re: gold regression vs BFD ld: __ehdr_start
- Authentication-results: sourceware.org; auth=none
- References: <20140330011513 dot D6435744AE at topped-with-meat dot com> <CAKOQZ8x2Aj3reAZKyEAAKKjcFFTu7KZY01WwXCHiOD0WLQC=_g at mail dot gmail dot com> <CAHACq4qsJMXQAXnjEGp3xQjfyztVkhXccEeLYvz7Qn=piJD40Q at mail dot gmail dot com> <CAB=4xhrE7=X1EwOFmOxmw4D8akKvYBDfruTknM6Lbce=4JGjuA at mail dot gmail dot com> <CAHACq4qz==mw2zqkez=JeZqj0kPJPwiC2RVO--=qFb87r84CFw at mail dot gmail dot com> <CAB=4xhrH5ap=uPuMPDoPhJ3gNZ-P0VFcKXLpbHbhGAakta=FDg at mail dot gmail dot com> <CAHACq4oOLFxnTpF4gGvjFAYgQoHyok=_mEiBpijSkAQ9PPV1fg at mail dot gmail dot com> <CAB=4xho=wbxV4AQD2W5ph92J3892k2y4rCX9yr0_Am7kd21TOg at mail dot gmail dot com> <CAHACq4rK8b6ccn9mqWzbDwXiUEkgxmLmY0MNfn8-uNe64PwP3g at mail dot gmail dot com>
On Tue, Apr 1, 2014 at 2:50 PM, Cary Coutant <firstname.lastname@example.org> 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
* 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.