Should linker merge symbol visibility for weak symbol

[H.J.]

There are

---
extern int foo (void) __attribute__((weak,__visibility__ ("hidden")));

int
foo (void)
{
return 1;
}

int
bar (void)
{
return foo ();
}
---

where "foo" is marked as weak and hidden. Can a compiler assume
that linker will make "foo" hidden even when there is a non-week
definition of "foo" in another relocatable file?

[Ian Lance Taylor]

"H.J." <hjl....@gmail.com> writes:

> Can a compiler assume
> that linker will make "foo" hidden even when there is a non-week
> definition of "foo" in another relocatable file?

The ELF ABI says "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." Since it specifically says "distinct
definitions" I assumed that that meant that visibility would propagate
from a weak definition to a strong definition.

I can't really tell whether that is a good idea or not. It's hard for
me to imagine a case where one would reasonably want a weak protected
definition combined with a strong definition with default visibility.

Ian

[H.J.]

On Jan 15, 7:23 am, Ian Lance Taylor <ianlancetay...@gmail.com> wrote:

> "H.J." <hjl.to...@gmail.com> writes:
> > Can a compiler assume
> > that linker will make "foo" hidden even when there is a non-week
> > definition of "foo" in another relocatable file?
>
> The ELF ABI says "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."  Since it specifically says "distinct
> definitions" I assumed that that meant that visibility would propagate
> from a weak definition to a strong definition.
>

I thought so myself. I assume gold does it. What do other ELF
linkers do?

H.J.

[Rod Evans]

The linker has to honor, and propagate the most restrictive visibility.
As the compiler may have "optimized" the code because of a restrictive
visibility, any less-restrictive promotion of that visibility could
compromise the compiled code.

--

Rod.

Everybody to Everest!

April 2010, I'll climb to Mt. Everest Base Camp as a fund raiser for
The Challenged Athletes Foundation - www.everybodytoeverest.com. Visit
www.everestchallenge.kintera.org/rie to show your support. Thanks!

[amodra]

I've been thinking a little more about this since making my comment
regarding weak symbols in http://sourceware.org/bugzilla/show_bug.cgi?id=11175#c2
(late at night and I hadn't read the visibility section of the abi
properly..)

If you accept that visibility on a reference is useful then clearly
the linker must merge visibility on all references with visibility on
the defining symbol. It's not immediately clear that visibility on a
weak defining symbol must also be merged, but I think that follows
too.

Consider: a) If a compiler sees a declaration with visibility
attributes it may emit code using that declaration before seeing a
later definition. This means that definitions in an object file need
to be treated exactly the same as references regarding merging of
visibility. Treating them differently would require that the
assembler emit two symbols with the same name, one for references and
one for definitions. I suppose that would be possible, but isn't the
way current assemblers work.
b) If it is legal for the compiler to merge a declaration with a
visibility attribute with a later declaration with a weak attribute,
then weak and strong references must also be treated the same.

(a) and (b) combined lead to the requirement that visibility should be
merged from a weak definition to a strong definition.