Re: RFC: PATCH: PR middle-end/20218: Can't use __attribute__ ((visibility ("hidden"))) to hide a symbol

["H. J. Lu" <hjl at lucon dot org>]

On Mon, Feb 28, 2005 at 07:43:05PM -0500, Andrew Pinski wrote:
> 
> On Feb 28, 2005, at 7:31 PM, H. J. Lu wrote:
> 
> >Gcc doesn't tell linker that a symbol, foo, is hidden when foo is
> >undefined. The problem is with
> >
> ># gcc -o libbar.so -shared bar.o libfoo.a
> >
> >gcc optimizes access to a hidden symbol, foo, in bar.o while foo is
> >defined in foo.o as a normal symbol. If foo isn't marked as hidden,
> >you will get a runtime/linktime error on ELF targets since the
> >optimization is only valid for hidden symbol.
> 
> You are explaining what this patch does really but not why this is
> needed and why binutils cannot just do it instead.  Also you still
> have not pointed out where in the elf standard it says this needs
> to be done this way?
> 
> GCC did tell foo is hidden via the TU where foo is declared, why is
> that not enough?  I think it would be undefined behavor if someone
> forgot to declare a function as hidden in TU where the hidden
> function is.

It is not someone's oversight. It is done as an optimization on
purpose. Normally, a global ELF symbol, foo, in a DSO can be preempted.
But sometimes you know it won't or you don't want it to be preempted
for one DSO. You only want it for libbar.o, not libx.so, even if
the definition of foo really comes from the same libfoo.a. You
shouldn't have to build libfoo.a twice, one with the normal foo and
the other with hidden foo. The ELF gABI allows a hidden reference to
a normal definition turns the normal definition into a hidden
definition. That is the whole purpose in gABI:

if any reference to or definition of a name is a symbol with a
non-default visibility attribute, the visibility attribute must be
propagated to the resolving symbol in the linked object. If different
visibility attributes are specified for distinct references to or
definitions of a symbol, the most constraining visibility attribute
must be propagated to the resolving symbol in the linked object. The
attributes, ordered from least to most constraining, are:
STV_PROTECTED, STV_HIDDEN and STV_INTERNAL.

The bottom line is that gcc can't and shouldn't assume a hidden
defition in a DSO will only come from a hidden defition in a .o
file. On ELF systems, a hidden defition in a DSO may result from
a hidden reference in one .o file and a normal defition in another
.o file. At the moment, gcc doesn't generate hidden reference and
assumes that its defition must be hidden. According to the gABI, it
is certainly not true.


H.J.