Re: [PATCH 2/3] gas/ELF: warn upon non-default visibility of local symbols
Jan Beulich <[email protected]>
| Newsgroups | gmane.comp.gnu.binutils |
|---|---|
| Message-ID | <[email protected]> |
On 23.06.2026 03:10, H.J. Lu wrote: > On Fri, May 8, 2026 at 2:54 PM Jan Beulich <[email protected]> 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? Jan