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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Apr 4, 2022 at 3:50 PM Ilya Leoshkevich <iii@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx>
> ---
> v1: https://lore.kernel.org/bpf/20220404102908.14688-1-iii@xxxxxxxxxxxxx/
> 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
>



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux