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

[Michael Matz]

Hello,

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

> (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).


Ciao,
Michael.