[Bug ld/33577] New: Undef weak symbols bound to Base version

[ro at gcc dot gnu.org]

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

            Bug ID: 33577
           Summary: Undef weak symbols bound to Base version
           Product: binutils
           Version: 2.46 (HEAD)
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
            Target: *-*-solaris2*, *-*-linux*

While working on a mini-testsuite for the Solaris ABI symbols (cf.
ld/emultempl/solaris2.em), I noticed an inconsistency between GNU ld and
Solaris
ld.  Consider the following testcase:

$ cat vers33.c
extern void show_undef_weak (void) __attribute__((weak));

void
foo (void)
{
  if (show_undef_weak)
    show_undef_weak ();
}
$ cat vers33.map
VERS_1 {
  global:
    foo;
  local:
    *;
};
$ gcc -fPIC -shared -o vers33.so vers33.c -Wl,--version-script vers33.map
$ objdump --dynamic-syms vers33.so|grep Base
0000000000000000  w   D  *UND*  0000000000000000  Base       
_ITM_deregisterTMCloneTable
0000000000000000  w   D  *UND*  0000000000000000  Base        __gmon_start__
0000000000000000  w   D  *UND*  0000000000000000  Base        show_undef_weak
0000000000000000  w   D  *UND*  0000000000000000  Base       
_ITM_registerTMCloneTable

Several undef weak symbols show up as bound to the Base version:
show_undef_weak
from the testcase, as well as a couple of others from crtbeginS.o and others.

This differs from the Solaris ld (which I consider as a reference for symbol
versioning given that Sun invented this stuff) and makes no sense at all:
those weak undef symbols certainly aren't an exported interface of the shared
objects, thus have no reason at all to show up as bound to the Base version in
the version *definition* (.gnu.version_d).  One might argue that they could be
in .gnu.version_r, but even that's not completely clear.

I tried to determine where this happens, but got lost in the maze of elflink.c

I'm attaching an initial patch with a testcase for this.

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