[Bug ld/19908] New: MIPS/ELF: Hidden and internal dynamic symbols produced

[address@hidden]

https://sourceware.org/bugzilla/show_bug.cgi?id=19908

            Bug ID: 19908
           Summary: MIPS/ELF: Hidden and internal dynamic symbols produced
           Product: binutils
           Version: 2.27 (HEAD)
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ld
          Assignee: address@hidden
          Reporter: address@hidden
  Target Milestone: ---
            Target: mips-linux-gnu

It is required by the the ELF gABI[1] that hidden and internal symbols
must not appear in the dynamic symbol table:

"A hidden symbol contained in a relocatable object must be either
removed or converted to STB_LOCAL binding by the link-editor when the
relocatable object is included in an executable file or shared object."

"An internal symbol contained in a relocatable object must be either
removed or converted to STB_LOCAL binding by the link-editor when the
relocatable object is included in an executable file or shared object."

The ELF linker usually respects this requirement, however in the case
where a dynamic symbol has been preallocated due to a reference of the
default export class aka visibility from the object being linked, and
then merged with a hidden or internal symbol definition from within the
same object, then the original export class is carried over to the
output dynamic symbol table, because while merging the generic ELF
linker only converts affected dynamic symbols to local when they are
defined or referenced by the object being linked and a dynamic object
involved in the link both at a time.

The dynamic symbol produced confuses then the dynamic loader at the run
time -- the hidden or internal export class is ignored and the symbol
follows preemption rules as with the default export class.

In the MIPS target it happens when `mips_elf_record_global_got_symbol'
creates a dynamic symbol when a call relocation is encountered.
Additionally if the undefined symbol referred by such a relocation does
specify the intended export class, then a local dynamic symbol is
created instead, which is harmless and allowed, but useless.  Normally
no local dynamic symbols are created, except for a single dummy one at
the beginning.

This can be reproduced with these simple C sources (bash syntax):

$ cat f0.c
#include <stdio.h>

int f1 (void);
int f2 (void);

int
main (void)
{
  printf ("%d\n", f1 ());
  printf ("%d\n", f2 ());
  return 0;
}
$ cat f1.c
int
f1 (void)
{
  return 1;
}
$ cat f2.c
int
f1 (void)
{
  return 2;
}
int
f2 (void)
{
  return f1 ();
}
$ mips-linux-gnu-gcc -fPIC -c f0.c
$ mips-linux-gnu-gcc -fPIC -fvisibility=hidden -c f1.c
$ mips-linux-gnu-gcc -fPIC -c f2.c
$ mips-linux-gnu-gcc -fPIC -shared -Wl,-soname,libf2.so -o libf2.so f2.o
$ mips-linux-gnu-gcc -Wl,-rpath,$(pwd) -L$(pwd) -o f f0.o f1.o -lf2
$ mips-linux-gnu-readelf --dyn-syms f
$ ./f
1
1
$ 

Add attribute annotation to `f1' in f0.c for the other (local) case (in
which case 1 and 2 will be correctly printed).

I'll be providing suitably reduced assembly sources as test cases along
the upcoming fix.

References:

[1] "System V Application Binary Interface - DRAFT - 24 April 2001",
    The Santa Cruz Operation, Inc., "Symbol Table",
    <http://www.sco.com/developers/gabi/2001-04-24/ch4.symtab.html>

-- 
You are receiving this mail because:
You are on the CC list for the bug.