Re: [PATCH] gas/ELF: Allow local symbol with hidden visibility

On 24.06.2026 02:23, H.J. Lu wrote:
> On Tue, Jun 23, 2026 at 10:22 PM 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
> 
> Here is the patch.

The "& ~STV_HIDDEN" is clearly bogus there. If we follow that alternative
interpretation of the spec, no warning should be issued for STV_INTERNAL
either. I'm also surprised you don't undo more of the respective testsuite
changes then (i.e. about everywhere I had added .global to avoid the
warning).

Jan