[1/4] elf: Disallow the empty symbol name

  Reject the empty symbol name, "".

PR ld/33456
* elflink.c (elf_link_add_object_symbols): Disallow the empty
symbol name.
  

On Tue, Sep 23, 2025 at 10:15:51AM +0800, H.J. Lu wrote:
> Reject the empty symbol name, "".
> 
> PR ld/33456
> * elflink.c (elf_link_add_object_symbols): Disallow the empty
> symbol name.

OK.
  

On 23.09.2025 13:20, Alan Modra wrote:
> On Tue, Sep 23, 2025 at 10:15:51AM +0800, H.J. Lu wrote:
>> Reject the empty symbol name, "".
>>
>> PR ld/33456
>> * elflink.c (elf_link_add_object_symbols): Disallow the empty
>> symbol name.
> 
> OK.

Where exactly is it stated that zero-length symbols aren't allowed?
gas allows me to make such a symbol. It isn't consistent though: It
doesn't allow me to make such a symbol global, for example. Imo as
long as such symbols aren't forbidden, this should be at most a
warning.

Jan
  

On Tue, Sep 23, 2025 at 10:34 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 23.09.2025 13:20, Alan Modra wrote:
> > On Tue, Sep 23, 2025 at 10:15:51AM +0800, H.J. Lu wrote:
> >> Reject the empty symbol name, "".
> >>
> >> PR ld/33456
> >> * elflink.c (elf_link_add_object_symbols): Disallow the empty
> >> symbol name.
> >
> > OK.
>
> Where exactly is it stated that zero-length symbols aren't allowed?
> gas allows me to make such a symbol. It isn't consistent though: It
> doesn't allow me to make such a symbol global, for example. Imo as
> long as such symbols aren't forbidden, this should be at most a
> warning.
>
> Jan

name here is a global symbol, which can't be an empty string.
I will update my commit message with

elf: Disallow the empty global symbol name

Reject the empty global symbol name, "".

        PR ld/33456
        * elflink.c (elf_link_add_object_symbols): Disallow the empty
        global symbol name.
  

On Wed, Sep 24, 2025 at 04:21:33AM +0800, H.J. Lu wrote:
> On Tue, Sep 23, 2025 at 10:34 PM Jan Beulich <jbeulich@suse.com> wrote:
> >
> > On 23.09.2025 13:20, Alan Modra wrote:
> > > On Tue, Sep 23, 2025 at 10:15:51AM +0800, H.J. Lu wrote:
> > >> Reject the empty symbol name, "".
> > >>
> > >> PR ld/33456
> > >> * elflink.c (elf_link_add_object_symbols): Disallow the empty
> > >> symbol name.
> > >
> > > OK.
> >
> > Where exactly is it stated that zero-length symbols aren't allowed?
> > gas allows me to make such a symbol. It isn't consistent though: It
> > doesn't allow me to make such a symbol global, for example. Imo as
> > long as such symbols aren't forbidden, this should be at most a
> > warning.
> >
> > Jan
> 
> name here is a global symbol, which can't be an empty string.
> I will update my commit message with
> 
> elf: Disallow the empty global symbol name
> 
> Reject the empty global symbol name, "".
> 
>         PR ld/33456
>         * elflink.c (elf_link_add_object_symbols): Disallow the empty
>         global symbol name.

This needs tweaking.  When I gave the OK for this patch, I'd seen that
you were changing global syms (locals can have empty names of course),
and thought that a global sym with name "" was useless:  We match
symbols by name when linking, obviously.  The problem is that STT_LOOS
thru STT_HIPROC symbol types might reasonably have empty names.

I'll commit the following after running another testsuite run.  It
fixes
sparc64-linux-gnu  +FAIL: selective2
sparc64-linux-gnu  +FAIL: selective3

	PR ld/33456
	* elflink.c (elf_link_add_object_symbols): Move new check later
	to give the backend add_symbol_hook a chance to remove symbols
	with empty names.

diff --git a/bfd/elflink.c b/bfd/elflink.c
index 0a0456177c2..5c8b822e36a 100644
--- a/bfd/elflink.c
+++ b/bfd/elflink.c
@@ -5096,13 +5096,6 @@ elf_link_add_object_symbols (bfd *abfd, struct bfd_link_info *info)
       if (name == NULL)
 	goto error_free_vers;
 
-      if (name[0] == '\0')
-	{
-	  _bfd_error_handler (_("%pB: corrupt symbol table"), abfd);
-	  bfd_set_error (bfd_error_bad_value);
-	  goto error_free_vers;
-	}
-
       if (isym->st_shndx == SHN_COMMON
 	  && (abfd->flags & BFD_PLUGIN) != 0)
 	{
@@ -5146,6 +5139,13 @@ elf_link_add_object_symbols (bfd *abfd, struct bfd_link_info *info)
 	    continue;
 	}
 
+      if (name[0] == '\0')
+	{
+	  _bfd_error_handler (_("%pB: corrupt symbol table"), abfd);
+	  bfd_set_error (bfd_error_bad_value);
+	  goto error_free_vers;
+	}
+
       /* Sanity check that all possibilities were handled.  */
       if (sec == NULL)
 	abort ();
  

On 25.09.2025 03:22, Alan Modra wrote:
> On Wed, Sep 24, 2025 at 04:21:33AM +0800, H.J. Lu wrote:
>> On Tue, Sep 23, 2025 at 10:34 PM Jan Beulich <jbeulich@suse.com> wrote:
>>>
>>> On 23.09.2025 13:20, Alan Modra wrote:
>>>> On Tue, Sep 23, 2025 at 10:15:51AM +0800, H.J. Lu wrote:
>>>>> Reject the empty symbol name, "".
>>>>>
>>>>> PR ld/33456
>>>>> * elflink.c (elf_link_add_object_symbols): Disallow the empty
>>>>> symbol name.
>>>>
>>>> OK.
>>>
>>> Where exactly is it stated that zero-length symbols aren't allowed?
>>> gas allows me to make such a symbol. It isn't consistent though: It
>>> doesn't allow me to make such a symbol global, for example. Imo as
>>> long as such symbols aren't forbidden, this should be at most a
>>> warning.
>>
>> name here is a global symbol, which can't be an empty string.

Why? Where's this stated?

>> I will update my commit message with
>>
>> elf: Disallow the empty global symbol name
>>
>> Reject the empty global symbol name, "".
>>
>>         PR ld/33456
>>         * elflink.c (elf_link_add_object_symbols): Disallow the empty
>>         global symbol name.
> 
> This needs tweaking.  When I gave the OK for this patch, I'd seen that
> you were changing global syms (locals can have empty names of course),
> and thought that a global sym with name "" was useless:  We match
> symbols by name when linking, obviously.

Yes, yet still: A single such symbol could exist in the name space. Unless
I've overlooked something in the spec.

Jan

>  The problem is that STT_LOOS
> thru STT_HIPROC symbol types might reasonably have empty names.
> 
> I'll commit the following after running another testsuite run.  It
> fixes
> sparc64-linux-gnu  +FAIL: selective2
> sparc64-linux-gnu  +FAIL: selective3
> 
> 	PR ld/33456
> 	* elflink.c (elf_link_add_object_symbols): Move new check later
> 	to give the backend add_symbol_hook a chance to remove symbols
> 	with empty names.
> 
> diff --git a/bfd/elflink.c b/bfd/elflink.c
> index 0a0456177c2..5c8b822e36a 100644
> --- a/bfd/elflink.c
> +++ b/bfd/elflink.c
> @@ -5096,13 +5096,6 @@ elf_link_add_object_symbols (bfd *abfd, struct bfd_link_info *info)
>        if (name == NULL)
>  	goto error_free_vers;
>  
> -      if (name[0] == '\0')
> -	{
> -	  _bfd_error_handler (_("%pB: corrupt symbol table"), abfd);
> -	  bfd_set_error (bfd_error_bad_value);
> -	  goto error_free_vers;
> -	}
> -
>        if (isym->st_shndx == SHN_COMMON
>  	  && (abfd->flags & BFD_PLUGIN) != 0)
>  	{
> @@ -5146,6 +5139,13 @@ elf_link_add_object_symbols (bfd *abfd, struct bfd_link_info *info)
>  	    continue;
>  	}
>  
> +      if (name[0] == '\0')
> +	{
> +	  _bfd_error_handler (_("%pB: corrupt symbol table"), abfd);
> +	  bfd_set_error (bfd_error_bad_value);
> +	  goto error_free_vers;
> +	}
> +
>        /* Sanity check that all possibilities were handled.  */
>        if (sec == NULL)
>  	abort ();
> 
>
  

On Thu, Sep 25, 2025 at 08:03:31AM +0200, Jan Beulich wrote:
> Yes, yet still: A single such symbol could exist in the name space. Unless
> I've overlooked something in the spec.

You do have a point, but I'll only take it seriously if you can
generate such a symbol in an ELF object file using gas.