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

[H.J. Lu]

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")));

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;
}

_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.  ELF spec
doesn't forbid the hidden visibility on a local symbol.  It is just a no-op.

-- 
H.J.