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

[Jan Beulich]

On 23.06.2026 09:37, H.J. Lu wrote:
> On Tue, Jun 23, 2026 at 3:17 PM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 23.06.2026 03:10, H.J. Lu wrote:
>>> On Fri, May 8, 2026 at 2:54 PM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 10.04.2026 16:17, Jan Beulich wrote:
>>>>> On 10.04.2026 15:35, Richard Earnshaw (foss) wrote:
>>>>>> On 10/04/2026 14:31, Jan Beulich wrote:
>>>>>>> The spec explicitly precludes STB_LOCAL together with STV_PROTECTED (and,
>>>>>>> implicity, STV_HIDDEN or STV_INTERNAL), so we better wouldn't entirely
>>>>>>> silently write out symbols violating this.
>>>>>>>
>>>>>>> LoongArch's tc_symbol_new_hook() simply needs dropping. If FAKE_LABEL_NAME
>>>>>>> symbols can end up global, marking them hidden would need doing elsewhere.
>>>>>>> There not being a need to make any testsuite adjustments suggests though
>>>>>>> that this won't normally (ever?) happen.
>>>>>>>
>>>>>>> A couple of testcases then also need adjustment.
>>>>>>> ---
>>>>>>> It would be nice to re-use an existing loop, yet the one in
>>>>>>> elf_frob_file_before_adjust() comes too early, as does elf_frob_symbol().
>>>>>>>
>>>>>>> An alternative may be to imply .global from .hidden etc also for defined
>>>>>>> symbols (as looks to have been implied by some of the testcases being
>>>>>>> adjusted). This would then require to reject .local when a visibility was
>>>>>>> already set.
>>>>>
>>>>> As you can see from this, ...
>>>>>
>>>>>>> I wonder what purpose STV_* serve with e.g. STT_SECTION. Yet I also wonder
>>>>>>> what purpose STB_* other than STB_LOCAL serve with STT_SECTION (seeing how
>>>>>>> bfd/elf.c:swap_out_syms() explicitly uses STB_GLOBAL).
>>>>>>>
>>>>>>> The TI C6x testcase adjustments suggest that PLT relocations are
>>>>>>> needlessly emitted by gas for non-default visibility globals.
>>>>>>
>>>>>>
>>>>>> Do we know that this won't cause issues for real code out in the wild?  Might it not be better to just treat .hidden as making the symbol global, but hidden?
>>>>>
>>>>> ... I'm wondering the same. I meant to be conservative (as to exposing new
>>>>> globals) for v1. If collectively we think changing the behavior that way
>>>>> makes sense, I'll be happy to try that out for v2.
>>>>
>>>> Having thought about this more, implying global from hidden (etc) feels more
>>>> risky than keeping things as they are in v1: People suddenly may face
>>>> duplicate symbol linker errors that way. Short of any other comments /
>>>> opinions, I'll get the series in as is.
>>>
>>> This warning isn't very useful and annoying:
>>>
>>> https://sourceware.org/bugzilla/show_bug.cgi?id=34312
>>
>> Your judgement feels pretty subjective to me. As said in the bug - people really
>> should decide: Do they want a local symbol or a hidden one?
>>
> 
> The source code is extracted from glibc:
> 
> #include <stdint.h>
> 
> extern void _dl_sysinfo_int80 (void)
>   __attribute__ ((visibility ("hidden")));

This results in a .hidden directive, which is in principle fine. In combination
with ...

> asm (".text\n\t"
>      ".type _dl_sysinfo_int80,@function\n\t"
>      "_dl_sysinfo_int80:\n\t"
>      "int $0x80;\n\t"
>      "ret");
> 
> uintptr_t
> foo ()
> {
>   return (uintptr_t) _dl_sysinfo_int80;

... this actual reference, arguably the compiler should also emit a .global
directive. It generally gets away without doing so because referenced symbols
which aren't otherwise defined are implicitly global (which, seeing how
other assemblers behave, can be argued as being a bug, but apparently is
"traditional behavior" on UNIXes).

> }
> 
> _dl_sysinfo_int80 is a local function, but it is defined in an asm statement.
> Since it is referenced in C, it needs to be declared as hidden.

It doesn't need to be. It could as well be declared non-hidden (accepting
that it then will be visible to the linker).

>  ELF spec
> doesn't forbid the hidden visibility on a local symbol.  It is just a no-op.

You did read

"The spec explicitly precludes STB_LOCAL together with STV_PROTECTED (and,
 implicity, STV_HIDDEN or STV_INTERNAL), so we better wouldn't entirely
 silently write out symbols violating this."

in the patch description, didn't you? If you think that's wrong, did you
then not consider going back to the ELF spec to find what exactly is said
there: "A symbol with STB_LOCAL binding may not have STV_PROTECTED
visibility." And then for STV_HIDDEN: "Such a symbol is necessarily
protected." I.e. what is said for STV_PROTECTED applies to STV_HIDDEN (and
STV_INTERNAL) as well, at least according to my interpretation of that
wording.

Jan