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

[Roland McGrath]

On Mon, Nov 18, 2013 at 4:46 PM, Maciej W. Rozycki
<macro@codesourcery.com> wrote:
>  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).

I am surprised to learn that PROVIDE_HIDDEN has those semantics.  Like you,
I am not convinced at all by the rationales given in the earlier threads.
But I'm not going to argue about what PROVIDE_HIDDEN does.

I think the argument against magic hiding of a symbol a user defined with
different visibility is even stronger when it's built-in magic like
__ehdr_start as opposed to something defined in a linker script.  (After
all, you can override the linker script with a different one.  But there is
no way to prevent the magic provision of __ehdr_start when it's undefined.)

Moreover, I now have maintainer approval for my patch as is and so I'm just
going to be done with it now.

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

I don't understand.  In what case is gold now inconsistent?
It already didn't perturb the visibility of a user-defined __ehdr_start.

>  And for the record [...]

Thanks for the background.  I still don't understand the MIPS oddities very
clearly, but I think I understand this issue adequately now.


Thanks,
Roland