This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] LD: PROVIDE_HIDDEN export class problem
- From: Alan Modra <amodra at gmail dot com>
- To: "Maciej W. Rozycki" <macro at codesourcery dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, Dave Anglin <dave dot anglin at nrc dot ca>, Jeff Law <law at redhat dot com>, binutils at sourceware dot org
- Date: Thu, 2 May 2013 11:04:29 +0930
- Subject: Re: [PATCH] LD: PROVIDE_HIDDEN export class problem
- References: <alpine dot DEB dot 1 dot 10 dot 1304292220350 dot 1453 at tp dot orcam dot me dot uk> <20130430012124 dot GA3074 at bubble dot grove dot modra dot org> <alpine dot DEB dot 1 dot 10 dot 1304300301170 dot 1453 at tp dot orcam dot me dot uk>
On Wed, May 01, 2013 at 05:04:29PM +0100, Maciej W. Rozycki wrote:
> I hoped the test cases provided were clear enough an illustration,
> however in this case perhaps a C code piece will be better. Given code
> produced from a definition like this:
> int foo = 1234;
> present in input and a linker script containing:
> PROVIDE_HIDDEN (foo = bar);
> I see no reason why foo should be assigned the hidden export class, as in
> this case "the linker will silently use the definition in the program."
> Likewise I'd expect the link not to fail even if there's been no bar
> definition anywhere.
Why would someone use PROVIDE_HIDDEN rather than plain PROVIDE if
they don't want "foo" hidden?
> Do you have a reference backing your claim that my interpretation is
Well, the current ld info doc says of PROVIDE_HIDDEN: "Similar to
PROVIDE. For ELF targeted ports, the symbol will be hidden and won't
be exported." Notice that it doesn't say "will be hidden .. if
provided". Hiding the symbol is unconditional according to the way I
Furthermore, I think the current behaviour is not really surprising,
given that not just a definition but even a reference (undefined
symbol) with STV_HIDDEN in a relocatable object file results in the
output symbol being hidden.
Australia Development Lab, IBM