Symbol collision

[152334H]

Low priority issue: symbols with multiple values

Observations

In libc6_2.27-3ubuntu1_amd64, there are two values for fmemopen:

$ grep fmemopen libc-database/db/libc6_2.27-3ubuntu1_amd64.symbols
fmemopen 0000000000089f20
fmemopen 0000000000089b00

This is because readelf provides two symbols for fmemopen:

$ readelf -Ws libc-database/db/libc6_2.27-3ubuntu1_amd64.symbols | grep fmemopen
1218: 0000000000089f20   550 FUNC    GLOBAL DEFAULT   13 fmemopen@GLIBC_2.2.5
1219: 0000000000089b00   595 FUNC    GLOBAL DEFAULT   13 fmemopen@@GLIBC_2.22

Where one of these symbols probably corresponds to __old_fmemopen in glibc's source.

There are a significant number of duplicate symbols for this libc, as well as other libcs (just testing 2.27 & 2.28 here):

$ symbols_with_dupes(){ for symb in $(sed 's/ .*//' < "$1" | sort | uniq -d); do grep ^$symb\  "$1"; done | sed 's/ .*//' | sort | uniq; }
$ symbols_with_dupes db/libc6_2.27-3ubuntu1_amd64.symbols
fmemopen
glob
glob64
nftw
nftw64
posix_spawn
posix_spawnp
pthread_cond_broadcast
pthread_cond_destroy
pthread_cond_init
pthread_cond_signal
pthread_cond_timedwait
pthread_cond_wait
quick_exit
realpath
regexec
sched_getaffinity
sched_setaffinity
_sys_nerr
sys_nerr
$ for f in db/libc6_2.27*.symbols db/libc6_2.28*.symbols; do symbols_with_dupes "$f" | wc -l; done
20
94
20
94
20
94
20
95
20
95

Solutions

No idea. For glibc in particular, it might be possible to prefer symbols that aren't tied to __old_* functions, but I see no solution for this issue in general.

[niklasb]

I don't think this is an issue. On libc.rip you can already find the libc version you mentioned by searching for either of the offsets, which is the only sane behavior in my opinion

[niklasb]

please re-open if you disagree or this leads to other issues which I am currently not seeing