| Message ID | 20220404225020.51029-1-iii@linux.ibm.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 568189310c2096e204674edd2f0da036cd50676a |
| Delegated to: | BPF |
| Headers | show |
| Series | [bpf-next,v2] libbpf: Support Debian in resolve_full_path() | expand |
| Context | Check | Description |
|---|---|---|
| bpf/vmtest-bpf-next-PR | success | PR summary |
| netdev/tree_selection | success | Clearly marked for bpf-next |
| netdev/apply | success | Patch already applied to bpf-next |
On Mon, Apr 4, 2022 at 3:50 PM Ilya Leoshkevich <iii@linux.ibm.com> wrote: > > attach_probe selftest fails on Debian-based distros with `failed to > resolve full path for 'libc.so.6'`. The reason is that these distros > embraced multiarch to the point where even for the "main" architecture > they store libc in /lib/<triple>. > > This is configured in /etc/ld.so.conf and in theory it's possible to > replicate the loader's parsing and processing logic in libbpf, however > a much simpler solution is to just enumerate the known library paths. > > Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> > --- > v1: https://lore.kernel.org/bpf/20220404102908.14688-1-iii@linux.ibm.com/ > v1 -> v2: Use a single return value (Andrii), get rid of nested #ifs, > simplify some of the conditions. > > tools/lib/bpf/libbpf.c | 41 ++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 40 insertions(+), 1 deletion(-) > > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c > index 6d2be53e4ba9..648dc8717e8d 100644 > --- a/tools/lib/bpf/libbpf.c > +++ b/tools/lib/bpf/libbpf.c > @@ -10707,15 +10707,54 @@ static long elf_find_func_offset(const char *binary_path, const char *name) > return ret; > } > > +static const char *arch_specific_lib_paths(void) > +{ > + /* > + * Based on https://packages.debian.org/sid/libc6. > + * > + * Assume that the traced program is built for the same architecture > + * as libbpf, which should cover the vast majority of cases. > + */ > +#if defined(__x86_64__) > + return "/lib/x86_64-linux-gnu"; > +#elif defined(__i386__) > + return "/lib/i386-linux-gnu"; > +#elif defined(__s390x__) > + return "/lib/s390x-linux-gnu"; > +#elif defined(__s390__) > + return "/lib/s390-linux-gnu"; > +#elif defined(__arm__) && defined(__SOFTFP__) > + return "/lib/arm-linux-gnueabi"; > +#elif defined(__arm__) && !defined(__SOFTFP__) > + return "/lib/arm-linux-gnueabihf"; > +#elif defined(__aarch64__) > + return "/lib/aarch64-linux-gnu"; > +#elif defined(__mips__) && defined(__MIPSEL__) && _MIPS_SZLONG == 64 > + return "/lib/mips64el-linux-gnuabi64"; > +#elif defined(__mips__) && defined(__MIPSEL__) && _MIPS_SZLONG == 32 > + return "/lib/mipsel-linux-gnu"; > +#elif defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ > + return "/lib/powerpc64le-linux-gnu"; > +#elif defined(__sparc__) && defined(__arch64__) > + return "/lib/sparc64-linux-gnu"; > +#elif defined(__riscv) && __riscv_xlen == 64 > + return "/lib/riscv64-linux-gnu"; > +#else > + return NULL; > +#endif > +} > + > /* Get full path to program/shared library. */ > static int resolve_full_path(const char *file, char *result, size_t result_sz) > { > - const char *search_paths[2]; > + const char *search_paths[3]; > int i; > > + memset(search_paths, 0, sizeof(search_paths)); memset() is an overkill, I just added = {} to search_path declaration. Applied to bpf-next, thanks! > if (strstr(file, ".so")) { > search_paths[0] = getenv("LD_LIBRARY_PATH"); > search_paths[1] = "/usr/lib64:/usr/lib"; > + search_paths[2] = arch_specific_lib_paths(); > } else { > search_paths[0] = getenv("PATH"); > search_paths[1] = "/usr/bin:/usr/sbin"; > -- > 2.35.1 >
Hello: This patch was applied to bpf/bpf-next.git (master) by Andrii Nakryiko <andrii@kernel.org>: On Tue, 5 Apr 2022 00:50:20 +0200 you wrote: > attach_probe selftest fails on Debian-based distros with `failed to > resolve full path for 'libc.so.6'`. The reason is that these distros > embraced multiarch to the point where even for the "main" architecture > they store libc in /lib/<triple>. > > This is configured in /etc/ld.so.conf and in theory it's possible to > replicate the loader's parsing and processing logic in libbpf, however > a much simpler solution is to just enumerate the known library paths. > > [...] Here is the summary with links: - [bpf-next,v2] libbpf: Support Debian in resolve_full_path() https://git.kernel.org/bpf/bpf-next/c/568189310c20 You are awesome, thank you!
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c index 6d2be53e4ba9..648dc8717e8d 100644 --- a/tools/lib/bpf/libbpf.c +++ b/tools/lib/bpf/libbpf.c @@ -10707,15 +10707,54 @@ static long elf_find_func_offset(const char *binary_path, const char *name) return ret; } +static const char *arch_specific_lib_paths(void) +{ + /* + * Based on https://packages.debian.org/sid/libc6. + * + * Assume that the traced program is built for the same architecture + * as libbpf, which should cover the vast majority of cases. + */ +#if defined(__x86_64__) + return "/lib/x86_64-linux-gnu"; +#elif defined(__i386__) + return "/lib/i386-linux-gnu"; +#elif defined(__s390x__) + return "/lib/s390x-linux-gnu"; +#elif defined(__s390__) + return "/lib/s390-linux-gnu"; +#elif defined(__arm__) && defined(__SOFTFP__) + return "/lib/arm-linux-gnueabi"; +#elif defined(__arm__) && !defined(__SOFTFP__) + return "/lib/arm-linux-gnueabihf"; +#elif defined(__aarch64__) + return "/lib/aarch64-linux-gnu"; +#elif defined(__mips__) && defined(__MIPSEL__) && _MIPS_SZLONG == 64 + return "/lib/mips64el-linux-gnuabi64"; +#elif defined(__mips__) && defined(__MIPSEL__) && _MIPS_SZLONG == 32 + return "/lib/mipsel-linux-gnu"; +#elif defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ + return "/lib/powerpc64le-linux-gnu"; +#elif defined(__sparc__) && defined(__arch64__) + return "/lib/sparc64-linux-gnu"; +#elif defined(__riscv) && __riscv_xlen == 64 + return "/lib/riscv64-linux-gnu"; +#else + return NULL; +#endif +} + /* Get full path to program/shared library. */ static int resolve_full_path(const char *file, char *result, size_t result_sz) { - const char *search_paths[2]; + const char *search_paths[3]; int i; + memset(search_paths, 0, sizeof(search_paths)); if (strstr(file, ".so")) { search_paths[0] = getenv("LD_LIBRARY_PATH"); search_paths[1] = "/usr/lib64:/usr/lib"; + search_paths[2] = arch_specific_lib_paths(); } else { search_paths[0] = getenv("PATH"); search_paths[1] = "/usr/bin:/usr/sbin";
attach_probe selftest fails on Debian-based distros with `failed to resolve full path for 'libc.so.6'`. The reason is that these distros embraced multiarch to the point where even for the "main" architecture they store libc in /lib/<triple>. This is configured in /etc/ld.so.conf and in theory it's possible to replicate the loader's parsing and processing logic in libbpf, however a much simpler solution is to just enumerate the known library paths. Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> --- v1: https://lore.kernel.org/bpf/20220404102908.14688-1-iii@linux.ibm.com/ v1 -> v2: Use a single return value (Andrii), get rid of nested #ifs, simplify some of the conditions. tools/lib/bpf/libbpf.c | 41 ++++++++++++++++++++++++++++++++++++++++- 1 file changed, 40 insertions(+), 1 deletion(-)