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

Jan Beulich jbeulich@suse.com
Fri May 8 06:54:41 GMT 2026


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.

Jan


More information about the Binutils mailing list