[PATCH bpf-next v2] libbpf: Support Debian in resolve_full_path()

[PATCH bpf-next v2] libbpf: Support Debian in resolve_full_path()

[Ilya Leoshkevich]

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));
 	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

Re: [PATCH bpf-next v2] libbpf: Support Debian in resolve_full_path()

[Andrii Nakryiko]

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
>

Re: [PATCH bpf-next v2] libbpf: Support Debian in resolve_full_path()

[patchwork-bot+netdevbpf]

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!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html