[Bug libc/2198] fix __hidden_ver1 when USER_LABEL_PREFIX is defined to something other than ""

[Bug libc/2198] fix __hidden_ver1 when USER_LABEL_PREFIX is defined to something other than ""

[vapier at gentoo dot org]

------- Additional Comments From vapier at gentoo dot org  2006-01-23 23:26 -------
Created an attachment (id=847)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=847&action=view)
libc-fix-hidden-ver-symbol-prefix.patch


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=2198

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/2198] New: fix __hidden_ver1 when USER_LABEL_PREFIX is defined to something other than ""

[vapier at gentoo dot org]

i'm playing with the blackfin target which defines USER_LABEL_PREFIX to "_" 
and i seem to be ending up with symbols with too many _ prefixes ... i traced 
it back to the libc_hidden_def() macro in libc-symbols.h

for example, this bit of code:
int __libc_close(int fd) { return fd; }
strong_alias(__libc_close,close)
libc_hidden_proto(close)
libc_hidden_def(close)

on a target where USER_LABEL_PREFIX is defined to "", we'd correctly end up 
with global symbols __libc_close and close, and an internal hidden __GI_close

however, on an a target where USER_LABEL_PREFIX is defined to "_", we'd end up 
with global symbols ___libc_close and _close, an internal hidden ___GI_close, 
and an undefined reference to ____GI_close

i'm thinking it's because __hidden_ver1() is incorrectly using 
__hidden_asmname() when defining the __EI_##name alias ... the alias name is 
processed by gcc itself which will insert USER_LABEL_PREFIX, so calling 
__hidden_asmname() which also inserts USER_LABEL_PREFIX for us generates an 
alias to a double prefixed asmname

if i change __hidden_ver1() to call __hidden_asmname1() with an empty prefix 
for the alias, my final object ends up with the correct prefixes ... sample 
file along with patch are attached, tested against x86_64 and bfin elf 
targets

current cvs:
$ gcc -c hidden-test.c && readelf -s hidden-test.o | grep close
     8: 0000000000000000    12 FUNC    GLOBAL DEFAULT    1 __libc_close
     9: 0000000000000000    12 FUNC    GLOBAL DEFAULT    1 close
    10: 0000000000000000    12 FUNC    GLOBAL HIDDEN    1 __GI_close
$ bfin-elf-gcc -c hidden-test.c && readelf -s hidden-test.o | grep close
     6: 00000000    14 FUNC    GLOBAL DEFAULT    1 ___libc_close
     7: 00000000    14 FUNC    GLOBAL HIDDEN    1 ___GI_close
     8: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND ____GI_close
with my simple patch:
$ gcc -DFIX -c hidden-test.c && readelf -s hidden-test.o | grep close
     8: 0000000000000000    12 FUNC    GLOBAL DEFAULT    1 __libc_close
     9: 0000000000000000    12 FUNC    GLOBAL DEFAULT    1 close
    10: 0000000000000000    12 FUNC    GLOBAL HIDDEN    1 __GI_close
$ bfin-elf-gcc -DFIX -c hidden-test.c && readelf -s hidden-test.o | grep close
     6: 00000000    14 FUNC    GLOBAL DEFAULT    1 ___libc_close
     7: 00000000    14 FUNC    GLOBAL DEFAULT    1 _close
     8: 00000000    14 FUNC    GLOBAL HIDDEN    1 ___GI_close

-- 
           Summary: fix __hidden_ver1 when USER_LABEL_PREFIX is defined to
                    something other than ""
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: minor
          Priority: P2
         Component: libc
        AssignedTo: drepper at redhat dot com
        ReportedBy: vapier at gentoo dot org
                CC: glibc-bugs at sources dot redhat dot com
 GCC build triplet: x86_64-linux
  GCC host triplet: bfin-uclinux


http://sourceware.org/bugzilla/show_bug.cgi?id=2198

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/2198] fix __hidden_ver1 when USER_LABEL_PREFIX is defined to something other than ""

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2006-02-03 22:06 -------
There is no support for archs with additional prefixes and I won't start adding
it.  That's a never ending stream of problems for *NO* value whatsoever.  Use a
different ABI.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX


http://sourceware.org/bugzilla/show_bug.cgi?id=2198

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.