Message ID | 20211118212341.19077-1-mark@klomp.org |
---|---|
State | Committed |
Headers |
Return-Path: <elfutils-devel-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 76BA2385781C for <patchwork@sourceware.org>; Thu, 18 Nov 2021 21:23:58 +0000 (GMT) X-Original-To: elfutils-devel@sourceware.org Delivered-To: elfutils-devel@sourceware.org Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 6E8703858422 for <elfutils-devel@sourceware.org>; Thu, 18 Nov 2021 21:23:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6E8703858422 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from reform (deer0x10.wildebeest.org [172.31.17.146]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id A3704302FBAF; Thu, 18 Nov 2021 22:23:48 +0100 (CET) Received: by reform (Postfix, from userid 1000) id 3094C2E812D6; Thu, 18 Nov 2021 22:23:48 +0100 (CET) From: Mark Wielaard <mark@klomp.org> To: elfutils-devel@sourceware.org Subject: [PATCH] tests: Add -ldl to dwfl_proc_attach_LDFLAGS Date: Thu, 18 Nov 2021 22:23:41 +0100 Message-Id: <20211118212341.19077-1-mark@klomp.org> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-10.1 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list <elfutils-devel.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/elfutils-devel>, <mailto:elfutils-devel-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/elfutils-devel/> List-Help: <mailto:elfutils-devel-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/elfutils-devel>, <mailto:elfutils-devel-request@sourceware.org?subject=subscribe> Cc: Mark Wielaard <mark@klomp.org> Errors-To: elfutils-devel-bounces+patchwork=sourceware.org@sourceware.org Sender: "Elfutils-devel" <elfutils-devel-bounces+patchwork=sourceware.org@sourceware.org> |
Series |
tests: Add -ldl to dwfl_proc_attach_LDFLAGS
|
|
Commit Message
Mark Wielaard
Nov. 18, 2021, 9:23 p.m. UTC
dwfl-proc-attach uses (overrides) dlopen (so it does nothing). This
seems to cause a versioned dlopen symbol to be pulled in when building
with LTO. Resulting in a link failure (when dlopen isn't integrated
into libc):
/usr/bin/ld: dwfl-proc-attach.o (symbol from plugin): undefined
reference to symbol 'dlopen@@GLIBC_2.2.5'
/usr/bin/ld: /usr/lib64/libdl.so.2: error adding symbols: DSO missing
from command line collect2: error: ld returned 1 exit status
So simply explicitly add -ldl to the LDFLAGS.
Signed-off-by: Mark Wielaard <mark@klomp.org>
---
tests/ChangeLog | 4 ++++
tests/Makefile.am | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
Comments
On Thu, Nov 18, 2021 at 10:23:41PM +0100, Mark Wielaard wrote: > dwfl-proc-attach uses (overrides) dlopen (so it does nothing). This > seems to cause a versioned dlopen symbol to be pulled in when building > with LTO. Resulting in a link failure (when dlopen isn't integrated > into libc): > > /usr/bin/ld: dwfl-proc-attach.o (symbol from plugin): undefined > reference to symbol 'dlopen@@GLIBC_2.2.5' > /usr/bin/ld: /usr/lib64/libdl.so.2: error adding symbols: DSO missing > from command line collect2: error: ld returned 1 exit status > > So simply explicitly add -ldl to the LDFLAGS. > > Signed-off-by: Mark Wielaard <mark@klomp.org> > --- > tests/ChangeLog | 4 ++++ > tests/Makefile.am | 2 +- > 2 files changed, 5 insertions(+), 1 deletion(-) > > diff --git a/tests/ChangeLog b/tests/ChangeLog > index a59cdd51..97cb3fa3 100644 > --- a/tests/ChangeLog > +++ b/tests/ChangeLog > @@ -1,3 +1,7 @@ > +2021-11-18 Mark Wielaard <mark@klomp.org> > + > + * Makefile.am (dwfl_proc_attach_LDFLAGS): Add -ldl. > + > 2021-11-05 Frank Ch. Eigler <fche@redhat.com> > > PR28430 > diff --git a/tests/Makefile.am b/tests/Makefile.am > index bfb8b13a..f212f9fb 100644 > --- a/tests/Makefile.am > +++ b/tests/Makefile.am > @@ -717,7 +717,7 @@ strptr_LDADD = $(libelf) > newdata_LDADD = $(libelf) > elfstrtab_LDADD = $(libelf) > dwfl_proc_attach_LDADD = $(libdw) > -dwfl_proc_attach_LDFLAGS = -pthread $(AM_LDFLAGS) > +dwfl_proc_attach_LDFLAGS = -pthread -ldl $(AM_LDFLAGS) Let's make clear what's going on here. First of all, dwfl-proc-attach.c does not use dlopen so it doesn't pull it in and doesn't need -ldl. In regular builds, dwfl-proc-attach.o is linked with ../libdw/libdw.so which in turn uses dlopen and is already linked with -ldl. When elfutils is configured with --enable-gprof or --enable-gcov, BUILD_STATIC is enabled and dwfl-proc-attach.o is linked with ../libdw/libdw.a -lz $(zip_LIBS) $(libelf) $(libebl) -ldl -lpthread which already contains -ldl. In any case, I fail to understand why dwfl-proc-attach might need an extra -ldl, especially in LDFLAGS which goes before LDADD in the linking command.
Hi Dmitry, On Fri, Nov 19, 2021 at 01:20:26AM +0300, Dmitry V. Levin wrote: > On Thu, Nov 18, 2021 at 10:23:41PM +0100, Mark Wielaard wrote: > > dwfl-proc-attach uses (overrides) dlopen (so it does nothing). This > > seems to cause a versioned dlopen symbol to be pulled in when building > > with LTO. Resulting in a link failure (when dlopen isn't integrated > > into libc): > > > > /usr/bin/ld: dwfl-proc-attach.o (symbol from plugin): undefined > > reference to symbol 'dlopen@@GLIBC_2.2.5' > > /usr/bin/ld: /usr/lib64/libdl.so.2: error adding symbols: DSO missing > > from command line collect2: error: ld returned 1 exit status > > > > So simply explicitly add -ldl to the LDFLAGS. > [...] > Let's make clear what's going on here. First of all, dwfl-proc-attach.c > does not use dlopen so it doesn't pull it in and doesn't need -ldl. > In regular builds, dwfl-proc-attach.o is linked with ../libdw/libdw.so > which in turn uses dlopen and is already linked with -ldl. > When elfutils is configured with --enable-gprof or --enable-gcov, > BUILD_STATIC is enabled and dwfl-proc-attach.o is linked with > ../libdw/libdw.a -lz $(zip_LIBS) $(libelf) $(libebl) -ldl -lpthread > which already contains -ldl. > In any case, I fail to understand why dwfl-proc-attach might need > an extra -ldl, especially in LDFLAGS which goes before LDADD > in the linking command. Agreed. It isn't totally clear why lto causes dlopen to be "pulled in" (which is probably the wrong technical term). But it really does. Instead of adding -ldl to LDFLAGS you can also remove the dlopen from the testcase: diff --git a/tests/dwfl-proc-attach.c b/tests/dwfl-proc-attach.c index d02e9fc0..0c5e8622 100644 --- a/tests/dwfl-proc-attach.c +++ b/tests/dwfl-proc-attach.c @@ -114,9 +114,5 @@ main (int argc __attribute__ ((unused)), So simply override dlopen and always return NULL so libdebuginfod (and libcurl) are never loaded. This test doesn't rely on libdebuginfod anyway. */ -void *dlopen (void) -{ - return NULL; -} #endif /* __linux__ */ Which also makes the linker happy, but removes the valgrind workaround. Cheers, Mark
* Dmitry V. Levin: > Let's make clear what's going on here. First of all, dwfl-proc-attach.c > does not use dlopen so it doesn't pull it in and doesn't need -ldl. > In regular builds, dwfl-proc-attach.o is linked with ../libdw/libdw.so > which in turn uses dlopen and is already linked with -ldl. > When elfutils is configured with --enable-gprof or --enable-gcov, > BUILD_STATIC is enabled and dwfl-proc-attach.o is linked with > ../libdw/libdw.a -lz $(zip_LIBS) $(libelf) $(libebl) -ldl -lpthread > which already contains -ldl. > In any case, I fail to understand why dwfl-proc-attach might need > an extra -ldl, especially in LDFLAGS which goes before LDADD > in the linking command. It may have to do with --as-needed that some builds use. If there are no pending undefined references, some linkers drop earlier shared object references with --as-needed (similar to what happens with static archives). The GCC LTO plugin results in ld looking at more objects in greater detail for some reason. Without LTO and --as-needed, you probably don't get a dlopen export (if you do not link with -E) because indirect dependencies are not consulted, breaking the valgrind workaround because there is no interposition. Thanks, Florian
On Fri, Nov 19, 2021 at 05:58:19PM +0100, Florian Weimer wrote: > * Dmitry V. Levin: > > > Let's make clear what's going on here. First of all, dwfl-proc-attach.c > > does not use dlopen so it doesn't pull it in and doesn't need -ldl. > > In regular builds, dwfl-proc-attach.o is linked with ../libdw/libdw.so > > which in turn uses dlopen and is already linked with -ldl. > > When elfutils is configured with --enable-gprof or --enable-gcov, > > BUILD_STATIC is enabled and dwfl-proc-attach.o is linked with > > ../libdw/libdw.a -lz $(zip_LIBS) $(libelf) $(libebl) -ldl -lpthread > > which already contains -ldl. > > In any case, I fail to understand why dwfl-proc-attach might need > > an extra -ldl, especially in LDFLAGS which goes before LDADD > > in the linking command. > > It may have to do with --as-needed that some builds use. If there are > no pending undefined references, some linkers drop earlier shared object > references with --as-needed (similar to what happens with static > archives). > > The GCC LTO plugin results in ld looking at more objects in greater > detail for some reason. Without LTO and --as-needed, you probably don't > get a dlopen export (if you do not link with -E) because indirect > dependencies are not consulted, breaking the valgrind workaround because > there is no interposition. Thanks. I suppose adding -rdynamic to dwfl_proc_attach_LDFLAGS should be a more correct fix.
Hi, On Sat, Nov 20, 2021 at 01:12:17AM +0300, Dmitry V. Levin wrote: > On Fri, Nov 19, 2021 at 05:58:19PM +0100, Florian Weimer wrote: > > It may have to do with --as-needed that some builds use. If there are > > no pending undefined references, some linkers drop earlier shared object > > references with --as-needed (similar to what happens with static > > archives). > > > > The GCC LTO plugin results in ld looking at more objects in greater > > detail for some reason. Without LTO and --as-needed, you probably don't > > get a dlopen export (if you do not link with -E) because indirect > > dependencies are not consulted, breaking the valgrind workaround because > > there is no interposition. > > Thanks. I suppose adding -rdynamic to dwfl_proc_attach_LDFLAGS should be > a more correct fix. That works. But I don't really understand why. Does the attached patch look OK to you? Thanks, Mark
Hi, On Sat, 2021-11-20 at 15:18 +0100, Mark Wielaard wrote: > On Sat, Nov 20, 2021 at 01:12:17AM +0300, Dmitry V. Levin wrote: > > On Fri, Nov 19, 2021 at 05:58:19PM +0100, Florian Weimer wrote: > > > It may have to do with --as-needed that some builds use. If there are > > > no pending undefined references, some linkers drop earlier shared object > > > references with --as-needed (similar to what happens with static > > > archives). > > > > > > The GCC LTO plugin results in ld looking at more objects in greater > > > detail for some reason. Without LTO and --as-needed, you probably don't > > > get a dlopen export (if you do not link with -E) because indirect > > > dependencies are not consulted, breaking the valgrind workaround because > > > there is no interposition. > > > > Thanks. I suppose adding -rdynamic to dwfl_proc_attach_LDFLAGS should be > > a more correct fix. > > That works. But I don't really understand why. > Does the attached patch look OK to you? I decided to simply disable LTO on Fedora 34, but still would like feedback on this patch. Thanks, Mark
On Sat, Nov 20, 2021 at 03:18:27PM +0100, Mark Wielaard wrote: > Hi, > > On Sat, Nov 20, 2021 at 01:12:17AM +0300, Dmitry V. Levin wrote: > > On Fri, Nov 19, 2021 at 05:58:19PM +0100, Florian Weimer wrote: > > > It may have to do with --as-needed that some builds use. If there are > > > no pending undefined references, some linkers drop earlier shared object > > > references with --as-needed (similar to what happens with static > > > archives). > > > > > > The GCC LTO plugin results in ld looking at more objects in greater > > > detail for some reason. Without LTO and --as-needed, you probably don't > > > get a dlopen export (if you do not link with -E) because indirect > > > dependencies are not consulted, breaking the valgrind workaround because > > > there is no interposition. > > > > Thanks. I suppose adding -rdynamic to dwfl_proc_attach_LDFLAGS should be > > a more correct fix. > > That works. But I don't really understand why. If I understand correctly, -rdynamic makes sure the dlopen symbol is exported by dwfl-proc-attach executable and interposes other dlopen symbols exported by libdl or libc. Without -rdynamic, there is a change that dlopen defined in dwfl-proc-attach.c is optimized out. > Does the attached patch look OK to you? Yes, thanks.
diff --git a/tests/ChangeLog b/tests/ChangeLog index a59cdd51..97cb3fa3 100644 --- a/tests/ChangeLog +++ b/tests/ChangeLog @@ -1,3 +1,7 @@ +2021-11-18 Mark Wielaard <mark@klomp.org> + + * Makefile.am (dwfl_proc_attach_LDFLAGS): Add -ldl. + 2021-11-05 Frank Ch. Eigler <fche@redhat.com> PR28430 diff --git a/tests/Makefile.am b/tests/Makefile.am index bfb8b13a..f212f9fb 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -717,7 +717,7 @@ strptr_LDADD = $(libelf) newdata_LDADD = $(libelf) elfstrtab_LDADD = $(libelf) dwfl_proc_attach_LDADD = $(libdw) -dwfl_proc_attach_LDFLAGS = -pthread $(AM_LDFLAGS) +dwfl_proc_attach_LDFLAGS = -pthread -ldl $(AM_LDFLAGS) elfshphehdr_LDADD =$(libelf) elfstrmerge_LDADD = $(libdw) $(libelf) dwelfgnucompressed_LDADD = $(libelf) $(libdw)