This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] LD: PROVIDE_HIDDEN export class problem


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 
> wrong?

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

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.

-- 
Alan Modra
Australia Development Lab, IBM


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]