From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17694 invoked by alias); 8 Jul 2019 20:49:19 -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 17547 invoked by uid 89); 8 Jul 2019 20:49:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.3 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=exporting, expose X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sourceware.org X-Spam-Level: X-HELO: gnu.wildebeest.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (212.238.236.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 08 Jul 2019 20:48:58 +0000 Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 84321300085B; Mon, 8 Jul 2019 22:48:52 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 398AA413CC0E; Mon, 8 Jul 2019 22:48:52 +0200 (CEST) Message-ID: Subject: Re: [RFC PATCH 0/2] elfutils: don't use dlopen() for libebl modules From: Mark Wielaard To: "Frank Ch. Eigler" , Omar Sandoval Cc: elfutils-devel@sourceware.org Date: Mon, 08 Jul 2019 20:49:00 -0000 In-Reply-To: <20190704005604.GD28142@redhat.com> References: <20190703213342.GB28142@redhat.com> <20190703213750.GA5055@vader> <20190703213953.GC28142@redhat.com> <20190703214609.GB5055@vader> <20190704005604.GD28142@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-2.el7) Mime-Version: 1.0 X-Spam-Flag: NO X-IsSubscribed: yes X-SW-Source: 2019-q3/txt/msg00026.txt.bz2 On Wed, 2019-07-03 at 20:56 -0400, Frank Ch. Eigler wrote: > > Some of the binaries use libebl, and although libebl is linked into lib= dw.so, > > the libebl symbols are not exported by libdw. So, libebl is linked in > > statically for the binaries. > >=20 > > This is why I suggested exporting those symbols from libdw.so. (I also > > considered adding a libebl.so, but that would have a circular dependenc= y with > > libdw.so, so they might as well be combined). >=20 > Ah, thanks for the (re-)explanation. IMHO, if the API is useful > enough to be used by mainline elfutils binaries, it is useful enough > to be used by others. So a +1 from me for solib-exporting them. The API is kind of useful enough to be used by the elfutils binaries directly (or they would use it). But that doesn't make them good, supportable API that we should expose through libdw.so. That would mean we promise they are fixed and supported essentially forever. It means, they are quick hacks that might work for now for internal use only. It might still be a good idea to expose/move some into libdw.so. But we should carefully review them one by one. This was done for example for the ELF/DWARF string table functions (Dwelf_Strtab and Dwelf_Strent). Or see my recent patch that replaces ebl->name with with a new libdw.so function dwelf_elf_e_machine_string (which works for any ELF e_machine value, not just for those which have a backend implementation): https://sourceware.org/ml/elfutils-devel/2019-q2/msg00130.html Cheers, Mark