On 04/09/2023 03:24, Hengqi Chen wrote: > Dynamic symbols in shared library may have the same name, for example: > > $ nm -D /lib/x86_64-linux-gnu/libc.so.6 | grep rwlock_wrlock > 000000000009b1a0 T __pthread_rwlock_wrlock@GLIBC_2.2.5 > 000000000009b1a0 T pthread_rwlock_wrlock@@GLIBC_2.34 > 000000000009b1a0 T pthread_rwlock_wrlock@GLIBC_2.2.5 > > $ readelf -W --dyn-syms /lib/x86_64-linux-gnu/libc.so.6 | grep rwlock_wrlock > 706: 000000000009b1a0 878 FUNC GLOBAL DEFAULT 15 __pthread_rwlock_wrlock@GLIBC_2.2.5 > 2568: 000000000009b1a0 878 FUNC GLOBAL DEFAULT 15 pthread_rwlock_wrlock@@GLIBC_2.34 > 2571: 000000000009b1a0 878 FUNC GLOBAL DEFAULT 15 pthread_rwlock_wrlock@GLIBC_2.2.5 > > There are two pthread_rwlock_wrlock symbols in .dynsym section of libc. > The one with @@ is the default version, the other is hidden. > Note that the version info is actually stored in .gnu.version and .gnu.version_d > sections of libc and the two symbols are at the same offset. > > Currently, specify `pthread_rwlock_wrlock`, `pthread_rwlock_wrlock@@GLIBC_2.34` > or `pthread_rwlock_wrlock@GLIBC_2.2.5` in bpf_uprobe_opts::func_name won't work. > Because there are two `pthread_rwlock_wrlock` in .dynsym sections without the > version suffix and both are global bind. > > This patchset adds symbol versioning ([0]) support for dynsym for uprobe, > so that we can handle the above case. > So it looks like patch 1 handles the above case for an unqualified uprobe where the addresses match; is there a reasonable approach to take for the unqualified version case where the addresses for different global symbol versions do not match (such as "use the most recent version")? Thanks! Alan > [0]: https://refspecs.linuxfoundation.org/LSB_3.0.0/LSB-PDA/LSB-PDA.junk/symversion.html > > Hengqi Chen (2): > libbpf: Resolve ambiguous matches at the same offset for uprobe > libbpf: Support symbol versioning for uprobe > > tools/lib/bpf/elf.c | 103 ++++++++++++++++++++++++++++++++++++++++---- > 1 file changed, 94 insertions(+), 9 deletions(-) > > -- > 2.39.3 >
