Re: [PATCH] Fix references to __ehdr_start when it cannot be defined

["Maciej W. Rozycki" <macro at codesourcery dot com>]

On Mon, 18 Nov 2013, Roland McGrath wrote:

> On Fri, Nov 15, 2013 at 11:49 PM, Alan Modra <amodra@gmail.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 
object).

 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:

http://sourceware.org/ml/binutils/2013-04/msg00315.html
http://sourceware.org/ml/binutils/2013-05/msg00003.html

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.

  Maciej