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

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