From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (wildebeest.demon.nl [212.238.236.112]) by sourceware.org (Postfix) with ESMTPS id 008373887023 for ; Wed, 8 Apr 2020 15:02:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 008373887023 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mark@klomp.org 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 C496E300D923; Wed, 8 Apr 2020 17:02:37 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 71C85413CE32; Wed, 8 Apr 2020 17:02:37 +0200 (CEST) Message-ID: <46b50532fef132b14a8ee37089616f328d0af210.camel@klomp.org> Subject: Re: How to drop all non-global/defined function declarations? From: Mark Wielaard To: Dodji Seketeli Cc: libabigail@sourceware.org Date: Wed, 08 Apr 2020 17:02:37 +0200 In-Reply-To: <86d08jprem.fsf@seketeli.org> References: <20200405200818.GA16021@wildebeest.org> <86d08jprem.fsf@seketeli.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-8.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-9.1 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libabigail@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libabigail mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 15:02:41 -0000 Hi Dodji, On Tue, 2020-04-07 at 11:38 +0200, Dodji Seketeli wrote: > From what I see, just invoking abidw on libfoo.so (without any > suppression specification) captures only the exported functions (which > have global function symbol in the binary) of the binary, that is: > create_foo, destroy_foo, get_foo and set_foo as well as free and malloc. Why are free and malloc included? They are explicitly marked as undefined in the symbol table and the xml abi definition doesn't include an elf-function-symbol for them? > The libfoo_frob function which is not exported (doesn't have a global > ELF symbol) is not captured. You are right, for my example, but I see internal, not exported, symbols in my actual library libelf, an example being __libelf_seterrno which is definitely LOCAL. Will try to come up with a smaller reproducer. But you can simply try by running libdw on libelf.so. __libelf_seterrno will be included if you have debuginfo installed (but not without debuginfo). > > But for some reason that doesn't drop the malloc and free function > > declarations. >=20 > Right. At the moment, there is no way to filter out a function that is > actually exported by the binary like this. I guess the original idea > was to prevent users from accidentally missing a potential ABI > incomptable change due to the toolchain or something like that. Also, > because those toolchain-generated functions usually don't come with > debug info, including them in the abixml file doesn't take much space. >=20 > But as usual, if you argue that this is would be a useful feature, then > we can add an option to handle this usecase. We just need to discuss > the details of that option, I guess. I think them being undefined in the symbol table make them unexported. They are just there to show the library consumes that symbol. That is also an abi issue, but not one I am interested in. Users of my library should assume that my library makes sure such symbols will be resolved (by having the correct DT_NEEDED entries), but they cannot use that information themselves to rely on those symbols being there. The main issue is that they are really noise. They don't come with an argument list or a real return type. And they make the xml abi file harder to compare (visually). My goal here is to have an xml abi file checked into git. Then when we update the abi, it should be accompanied by a change in the xml abi file. The smaller and more concise we can make the xml abi file the clearer it is what we are exactly changing that impacts the abi. Thanks, Mark