This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] Fix references to __ehdr_start when it cannot be defined
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Roland McGrath <mcgrathr at google dot com>, Alan Modra <amodra at gmail dot com>
- Cc: "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Tue, 19 Nov 2013 00:46:43 +0000
- Subject: Re: [PATCH] Fix references to __ehdr_start when it cannot be defined
- Authentication-results: sourceware.org; auth=none
- References: <CAB=4xhrAu+MTMR2OTyxvSr-zUXdi=WC7-47AmuQqoVL3tOccvA at mail dot gmail dot com> <alpine dot DEB dot 1 dot 10 dot 1311080008160 dot 21686 at tp dot orcam dot me dot uk> <CAB=4xhr_eQE41vMk1LAy4pEk7HUQC55QrddE7pvYp9AbijT+1w at mail dot gmail dot com> <20131116074950 dot GG22514 at bubble dot grove dot modra dot org> <CAB=4xhp8rKxzsmqtdfp15eUVhC1Yy5Jn=Og=9woxYhWpsAU+8A at mail dot gmail dot com>
On Mon, 18 Nov 2013, Roland McGrath wrote:
> On Fri, Nov 15, 2013 at 11:49 PM, Alan Modra <email@example.com> wrote:
> > Right, and bfd_elf_record_link_assignment was designed to handle
> > defining symbols.. I owe you and Maciej an apology, since it was my
> > suggestion to use bfd_elf_record_link_assignment here. Let's go back
> > to Maciej's original submission, modified somewhat.
Alan, thanks for stepping in and sorting out this issue.
> > Maciej, this gets FAIL: MIPS magic __ehdr_start symbol test 2 (o32)
> > because the linker script defines __ehdr_start and so the symbol
> > is not made hidden and forced_local. Should we update the testcase,
> > or do you think __ehdr_start should always be hidden? The latter can
> > be done by simply removing the h->root.type tests.
> IMHO the test case is wrong. The original intent with __ehdr_start when
> I implemented it was that it was doing the equivalent of PROVIDE. After
> Maciej's change (which I agree with), it is doing the equivalent of
> PROVIDE_HIDDEN. This symbol name should not be deeply magical--that is
> just bizarre and unlike any other feature I know of. If the user is
> defining it, all the details of the symbol are up to the user. If the
> user refers to it without defining it, we provide it as STV_HIDDEN just
> like any PROVIDE_HIDDEN case.
Roland, the test case isn't right or wrong, it merely reflects the
current semantics. I have no objections to making __ehdr_start so special
as to change the attribute depending on whether it's defined by a user
object or provided by the linker. In fact I find it natural this way,
however please note that it's going to be a unique arrangement that cannot
be recreated for another, non-special symbol with the available command
line and linker script syntax as this will match neither PROVIDE (that'd
make a symbol provided by the linker global and respect the export class
chosen by the user otherwise) nor PROVIDE_HIDDEN (that'd make it hidden no
matter if provided by the linker or already defined as global by a user
In fact we already had a discussion about PROVIDE_HIDDEN where I
suggested making the command not hide symbols defined by user objects, but
my proposal was rejected -- see the two parts of the thread here:
So while I'm in favour to your approach, with the current semantics of
PROVIDE and PROVIDE_HIDDEN it is your proposal that is making an exception
to the usual rules and not my previous implementation (that you correctly
observed mimics PROVIDE_HIDDEN).
> Here is a new version of my patch that uses your code to set STV_HIDDEN
> when providing the symbol. I've adjusted the MIPS test case not to
> expect magic hiding of a user-defined symbol with the name __ehdr_start.
> I've also added a generic test case that verifies an explicit
> linker-script definition doesn't get its visibility perturbed.
> Tested on mips-linux-gnu, x86_64-linux-gnu, and x86_64-nacl.
Thanks, I have tested it as well and I see no problems with it. However
I think in this case gold/layout.cc should be adjusted accordingly.
And for the record -- since you were surprised as to why a hidden symbol
should take any effect on dynamic sections -- the original MIPS SVR4 psABI
has been formulated such that there is no dynamic relocation defined and
used to relocate local GOT entries. Instead the GOT is split into the
local part that comes first and the global part that goes next. The point
of the split is indicated by the DT_MIPS_LOCAL_GOTNO dynamic section tag
and all the GOT entries before that point undergo implicit local
relocation. Therefore local GOT entries cannot be inserted at arbitrary
places in the GOT. Then the point of the split is determined by
bfd_elf_size_dynamic_sections and therefore no further local symbols can
be created afterwards.
Furthermore the ABI does not use a PLT or copy relocations, not even for
executables and all final binaries are PIC, so all the consequences apply,
local GOT entries still need to be made, although normally they won't need
any run-time relocation as the base address is supposed to be always 0.
To avoid these drawbacks an ABI extension has been developed that uses a
PLT and copy relocations for executables, but the original MIPS SVR4 psABI
remains supported (and also the default for the 64-bit "new" ABIs).
I hope this explanation makes the matter clear, please feel free to ask
further if I missed anything you might be interested in.