From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30056 invoked by alias); 27 Apr 2019 15:49:41 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 30028 invoked by uid 48); 27 Apr 2019 15:49:37 -0000 From: "mark at klomp dot org" To: elfutils-devel@sourceware.org Subject: [Bug backends/24488] ebl_openbackend might use wrong library search path Date: Sat, 27 Apr 2019 15:49:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: elfutils X-Bugzilla-Component: backends X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: mark at klomp dot org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: mark at klomp dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2019-q2/txt/msg00028.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D24488 Mark Wielaard 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 --- (In reply to Mark Wielaard from comment #2) > We discussed this on irc a bit and the real bug is indeed in the sanitize= r. > When overriding ldopen it doesn't obey the RUNPATH set in libdw.so. And s= o=20 >=20 > But on Fedora it still works because ebl_openbackend first tries to load > from: >=20 > #ifndef LIBEBL_SUBDIR > # define LIBEBL_SUBDIR PACKAGE > #endif > #define ORIGINDIR "$ORIGIN/../$LIB/" LIBEBL_SUBDIR "/" >=20 > /* 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"); >=20 > void *h =3D dlopen (dsoname, RTLD_LAZY); >=20 > 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=20 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).=20 > 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 libd= w we need the ../$LIB/ part to get from prefix bin/ dir to the corresponding pre= fix /lib[64] dir. The original idea was that you could find the ebl backend libraries relativ= e 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 sa= me search path for binaries and libraries (../ doesn't get us to the top of the install prefix). --=20 You are receiving this mail because: You are on the CC list for the bug.