[Bug libdw/24488] abidw: wrong results when running with ASAN runtim

[Bug libdw/24488] abidw: wrong results when running with ASAN runtim

[maennich at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=24488

Matthias Maennich <maennich at google dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |elfutils-devel at sourceware dot o
                   |                            |rg
          Component|default                     |libdw
            Product|libabigail                  |elfutils

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug backends/24488] abidw: wrong results when running with ASAN runtim

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=24488

Mark Wielaard <mark at klomp dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2019-04-26
                 CC|mjw at fedoraproject dot org       |mark at klomp dot org
          Component|libdw                       |backends
           Assignee|dodji at redhat dot com            |mark at klomp dot org
     Ever confirmed|0                           |1

--- Comment #2 from Mark Wielaard <mark at klomp dot org> ---
We discussed this on irc a bit and the real bug is indeed in the sanitizer.
When overriding ldopen it doesn't obey the RUNPATH set in libdw.so. And so 

But on Fedora it still works because ebl_openbackend first tries to load from:

#ifndef LIBEBL_SUBDIR
# define LIBEBL_SUBDIR PACKAGE
#endif
#define ORIGINDIR "$ORIGIN/../$LIB/" LIBEBL_SUBDIR "/"

        /* Give it a try.  At least the machine type matches.  First
           try to load the module.  */
        char dsoname[100];
        strcpy (stpcpy (stpcpy (dsoname, ORIGINDIR "libebl_"),
                        machines[cnt].dsoname),
                ".so");

        void *h = dlopen (dsoname, RTLD_LAZY);

This doesn't work on Debian based systems though.
$LIB will expand to "lib" (on 32bit systems) or "lib64" (on 64bit systems).
But on Debian (amd64) everything is installed under /usr/lib/x86_64-linux-gnu

It is not immediately clear why we use ../$LIB/
I think we can just use #define ORIGINDIR "$ORIGIN/" LIBEBL_SUBDIR "/"

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug backends/24488] ebl_openbackend might use wrong library search path

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=24488

Mark Wielaard <mark at klomp dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|abidw: wrong results when   |ebl_openbackend might use
                   |running with ASAN runtim    |wrong library search path

--- Comment #3 from Mark Wielaard <mark at klomp dot org> ---
(In reply to Mark Wielaard from comment #2)
> We discussed this on irc a bit and the real bug is indeed in the sanitizer.
> When overriding ldopen it doesn't obey the RUNPATH set in libdw.so. And so 
> 
> But on Fedora it still works because ebl_openbackend first tries to load
> from:
> 
> #ifndef LIBEBL_SUBDIR
> # define LIBEBL_SUBDIR PACKAGE
> #endif
> #define ORIGINDIR "$ORIGIN/../$LIB/" LIBEBL_SUBDIR "/"
> 
>         /* Give it a try.  At least the machine type matches.  First
>            try to load the module.  */
>         char dsoname[100];
>         strcpy (stpcpy (stpcpy (dsoname, ORIGINDIR "libebl_"),
>                         machines[cnt].dsoname),
>                 ".so");
> 
>         void *h = dlopen (dsoname, RTLD_LAZY);
> 
> This doesn't work on Debian based systems though.
> $LIB will expand to "lib" (on 32bit systems) or "lib64" (on 64bit systems).
> But on Debian (amd64) everything is installed under /usr/lib/x86_64-linux-gnu

Some experiments on Debian seem to point to $LIB expanding to
lib/x86_64-linux-gnu. But I cannot find any documentation for that. Debian's
own documentation 
https://manpages.debian.org/unstable/manpages/ld.so.8.en.html says:

  $LIB (or equivalently ${LIB})
    This expands to lib or lib64 depending on the architecture (e.g., on
x86-64, it expands to lib64 and on x86-32, it expands to lib). 

> It is not immediately clear why we use ../$LIB/
> I think we can just use #define ORIGINDIR "$ORIGIN/" LIBEBL_SUBDIR "/"

That won't work. The path is used for both binaries and libraries that rely on
ebl backends. When built in a binary (say eu-elflint) that doesn't use libdw we
need the ../$LIB/ part to get from prefix bin/ dir to the corresponding prefix
/lib[64] dir.

The original idea was that you could find the ebl backend libraries relative to
whereever the binary (eu-xxx) or library (libdw.so) were installed.

The problem on systems that use a deeper library paths we cannot use the same
search path for binaries and libraries (../ doesn't get us to the top of the
install prefix).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug backends/24488] ebl_openbackend might use wrong library search path

[fche at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=24488

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fche at redhat dot com

--- Comment #4 from Frank Ch. Eigler <fche at redhat dot com> ---
Is it worth reconsidering the dynamic loading model for libebl?  Each target
backend consists of about 30kB of stripped .so content, for half a megabyte in
total.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug backends/24488] ebl_openbackend might use wrong library search path

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=24488

--- Comment #5 from Mark Wielaard <mark at klomp dot org> ---
(In reply to Frank Ch. Eigler from comment #4)
> Is it worth reconsidering the dynamic loading model for libebl?  Each target
> backend consists of about 30kB of stripped .so content, for half a megabyte
> in total.

Yes, I believe that also makes sense. Certainly for the "native" backend. But
maybe for all. Note that DTS does this (to make static linking possible, so
things work without the backend shared libraries being installed). But it is a
bit of an ugly hack atm. See the mjw/RH-DTS branch. It might make sense to
clean that up and maybe make it configurable which backends are built in.

Still it would be helpful to better understand how the dlopen search path and
substitutions work on Debian based systems.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug backends/24488] ebl_openbackend might use wrong library search path

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=24488

--- Comment #6 from Mark Wielaard <mark at klomp dot org> ---
Created attachment 11770
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11770&action=edit
Factor out loading of ebl backend library and try multiple times with bin/lib
origin paths

I think we just have to try twice. The first time using the $ORIGIN as if it
came from an executable (in bin/) and then using the $ORIGIN as if it came from
an library (in lib[64]/ or lib/<arch>/). So first time using ../$LIB and second
time just with the elfutils EBL_SUBDIR.

The first is what we do now and always work on multilib systems. The second try
works when loading relative to a library whether on a multilib or multiarch
system.

Then we use the same fallback (not using any path) we used already (to take
advantage of any RPATH or LD_LIBRARY_PATH setting).

Could someone try this out on a Debian based system to see if it works as
intended?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug backends/24488] ebl_openbackend might use wrong library search path

[maennich at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=24488

--- Comment #7 from Matthias Maennich <maennich at google dot com> ---
I tried the patch against libdw1-0.168-1 on Debian Stretch. It cleanly applied
and solved the very issue I saw.

Thanks!

[1] https://packages.debian.org/stretch/libdw1

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug backends/24488] ebl_openbackend might use wrong library search path

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=24488

Mark Wielaard <mark at klomp dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #8 from Mark Wielaard <mark at klomp dot org> ---
(In reply to Matthias Maennich from comment #7)
> I tried the patch against libdw1-0.168-1 on Debian Stretch. It cleanly
> applied and solved the very issue I saw.

Thanks for testing. Pushed as follows:

commit bfcf8b1fee8805b42b262baf352c58574df59362 (HEAD -> master, origin/master,
origin/HEAD)
Author: Mark Wielaard <mark@klomp.org>
Date:   Sat May 11 16:55:01 2019 +0200

    libebl: Try harder to find backend library in bin and lib origin paths.

    eblopenbackend tries to find libraries based on the $ORIGIN/../$LIB/
    path. But depending on whether the system is multilib or multiarch
    this doesn't always work. On multilib systems $LIB is always just one
    directory deep (it is either .../lib or .../lib64) but on multiarch
    systems it can be multiple directories deep (.../lib/x86_64-linux-gnu).
    This means that on multiarch systems $ORIGIN/../$LIB only works for
    binaries (where origin is .../bin/), but not for libraries.

    Most of the time it still works because of RPATH which is tried afterwards.
    But RPATH processing does not always work reliable.

    So try multiple paths first. The first time using the $ORIGIN as if it
    came from an executable (in bin/) and then using the $ORIGIN as if it
    came from an library (in lib[64]/ or lib/<arch>/). So first time using
    ../$LIB and second time just with the elfutils EBL_SUBDIR.

    The first is what we do now and always work on multilib systems. The
    second try works when loading relative to a library whether on a multilib
    or multiarch system.

    Then we use the same fallback (not using any path) we used already
    (to take advantage of any RPATH or LD_LIBRARY_PATH setting).

    https://sourceware.org/bugzilla/show_bug.cgi?id=24488

    Signed-off-by: Mark Wielaard <mark@klomp.org>

-- 
You are receiving this mail because:
You are on the CC list for the bug.