| Message ID | 20230904022444.1695820-1-hengqi.chen@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | libbpf: Support symbol versioning for uprobe | expand |
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 >
Hi, Alan: On 9/4/23 16:38, Alan Maguire wrote: > 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 Yes. > 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! > No ideas, need further investigations. For such cases, I guess users should specify func@LIB_VERSION. > 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 >> --- Hengqi
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. [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