Re: [PATCH 2/3] gas/ELF: warn upon non-default visibility of local symbols

On Tue, Jun 23, 2026 at 11:19:21PM -0700, Fangrui Song wrote:
> On Tue, Jun 23, 2026 at 7:23 AM Jan Beulich <[email protected]> wrote:
> >
> > On 23.06.2026 15:54, Michael Matz wrote:
> > > On Tue, 23 Jun 2026, Jan Beulich wrote:
> > >>> I think that's a misinterpretation.  "a symbol is protected" is different
> > >>> from "a symbol has STV_PROTECTED visibility".  The former is defined in
> > >>> the section for the latter:
> > >>>
> > >>>   A symbol defined in the current component is protected if it is visible
> > >>>   in other components but cannot be preempted. Any reference to such a
> > >>>   symbol from within the defining component must be resolved to the
> > >>>   definition in that component, even if there is a definition in another
> > >>>   component that would interpose by the default rules. A symbol with
> > >>>   STB_LOCAL binding will not have STV_PROTECTED visibility.
> > >>>
> > >>> and _that definition_ is invoked by STV_HIDDEN:
> > >>>
> > >>>   A symbol defined in the current component is hidden if its name is not
> > >>>   visible to other components. Such a symbol is necessarily protected.
> > >>>
> > >>> IMHO it's clear that a symbol hence "can be protected" without having its
> > >>> visibility be STV_PROTECTED.  Namely when it is STV_HIDDEN: its then
> > >>> protected _and_ hidden (which is of course redundant, because hidden
> > >>> implies protected, but as we are word-smithing, lets be precise).
> > >>>
> > >>> That a STB_LOCAL symbol cannot have STV_PROTECTED visibility doesn't
> > >>> transfer to STV_HIDDEN from this wording, and from nothing else either,
> > >>> conceptually binding and visibility are orthogonal concepts and this
> > >>> specific disallowance for the STB_LOCAL+STV_PROTECTED combination is ...
> > >>> well, specific.  That is the wart, not that STB_LOCAL+STV_HIDDEN was
> > >>> "forgotten" to be disallowed.
> > >>
> > >> IOW what you're suggesting as interpretation is that while STV_PROTECTED
> > >> and STB_LOCAL may not combine, the visibility-wise more restricting
> > >> STV_HIDDEN may combine with STB_LOCAL?
> > >
> > > Yes.
> > >
> > >> Make no sense to me, I'm afraid.
> > >
> > > That may be, and I agree that creating such situation willingly would
> > > be suspect.  But as we just saw, such combinations might be created
> > > by an unlucky reality.
> >
> > Because of shortcomings in the tools used. I bet if there had been a
> > warning, the approach chosen would have been a different one. (The
> > approach chosen also isn't portable to non-ELF targets.)
> >
> > >  And again: binding and visiblity are _orthogonal_.
> > > One is for link-editing, the other for runtime linking.  In principle all
> > > combinations are "okay" (if questionable), and have obvious
> > > implementations.  But it's only that specific combination
> > > STB_LOCAL+STV_PROTECTED that is explicitely made ill-formed in the spec
> > > (despite it being also obviously implementable).  So, sure, warning on
> > > that combination can be done on the grounds of following the spec.  But no
> > > other combination is so spelled out, so there's no basis for trying to
> > > disallow them.
> >
> > As with many things in specs, what's spelled out and what's implied
> > is a matter of interpretation. As I think follows from earlier replies,
> > I can see that there is room for interpretation here, and hence mine
> > may not match what was intended. Yet we won't know for any other
> > interpretation either, seeing the state the ELF spec is in.
> >
> > If others are in favor of following your interpretation, then I'm not
> > going to stand in the way. But as of now it's not going to be me to
> > make a patch to that effect. I simply couldn't write a description
> > for it in good faith.
> >
> > >> (And would also make the implementation harder.)
> > >
> > > If a warning is too costly to implement, then it shouldn't be there.
> > > Though it seems surprising that checking for "is_local && is_protected"
> > > should be materially more difficult than for "is_local && !is_default_vis".
> > > (I haven't looked at the concrete patch, though).
> >
> > Well, you may be right and it's not really more complex.
> >
> > Jan
> 
> Since known ELF linkers ignore visibility on STB_LOCAL symbols, this
> warning is likely unnecessary.

I agree.

> We shouldn't over-read the gABI rule
> stating that "A symbol with STB_LOCAL binding may not have
> STV_PROTECTED visibility."

Yes, the gABI could have omitted the rule you quote and simply stated
that symbol binding takes precedence over visibility.

I see some utility in gas warning about local protected symbols
because it is a contradiction, with STV_PROTETED "visible in other
components but not preemptable" while STB_LOCAL is "not visible
outside the object file containing their definition".  So perhaps
worth warning naive users that ".protected" doesn't make a symbol
global.

> For STV_HIDDEN, linkers are required to convert the symbol to
> STB_LOCAL. Retaining STV_HIDDEN is useful because it documents why the
> symbol became STB_LOCAL in the first place.
> It's natural to allow STV_HIDDEN/STB_LOCAL in assemblers as well.

-- 
Alan Modra