From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by sourceware.org (Postfix) with ESMTPS id 162BC385B835 for ; Fri, 10 Apr 2020 08:48:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 162BC385B835 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=seketeli.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dodji@seketeli.org X-Originating-IP: 91.166.131.130 Received: from localhost (91-166-131-130.subs.proxad.net [91.166.131.130]) (Authenticated sender: dodj@seketeli.org) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 8281C1C0118; Fri, 10 Apr 2020 08:48:16 +0000 (UTC) Received: by localhost (Postfix, from userid 1001) id 42EFF1A4B73; Fri, 10 Apr 2020 10:48:14 +0200 (CEST) From: Dodji Seketeli To: Mark Wielaard Cc: libabigail@sourceware.org Subject: Re: How to drop all non-global/defined function declarations? Organization: Me, myself and I References: <20200405200818.GA16021@wildebeest.org> <86d08jprem.fsf@seketeli.org> <46b50532fef132b14a8ee37089616f328d0af210.camel@klomp.org> X-Operating-System: Red Hat Enterprise Linux Server 7.7 X-URL: http://www.seketeli.net/~dodji Date: Fri, 10 Apr 2020 10:48:14 +0200 In-Reply-To: <46b50532fef132b14a8ee37089616f328d0af210.camel@klomp.org> (Mark Wielaard's message of "Wed, 08 Apr 2020 17:02:37 +0200") Message-ID: <86blnzohf5.fsf@seketeli.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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: Fri, 10 Apr 2020 08:48:20 -0000 Hello Mark, Mark Wielaard a =C3=A9crit: > 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? They are included because we capture all global function and variable symbols, including those that are undefined. That can be useful down the road for tools like abicompat: https://sourceware.org/libabigail/manual/abicompat.html. It's true that they are not defined by the librarie so if you know that you need those, so yeah, maybe we should add an option to get rid of them. Right now, you can't. > >> 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). >From the top of my head, I'd say that is a bug then. But I'd need to look into it deeper to be sure. > >> > 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. You are right. > That is also an abi issue, but not one I am interested in. Well, that's the gotcha I think :-) In your particular use case, you are not interested. But others might use that information, to for instance, build the transitive closure of dependencies (in terms of either symbols or libraries) of the binary which ABI is being modelled by the current abixml file. That's precisely why we are adding this information in. As I said above, the abicompat tool need that information, for instance. Users of the library might need it too. [...] > > The main issue is that they are really noise. They don't come with an > argument list or a real return type. If you think having that information in is a real problem for you, we can find a way to let you remove it. But I am not yet convinced that it's better to remove it by default because it might be useful for other use cases, and as it stands right now, the size of undefined entry points in the abixml file is quite small. > And they make the xml abi file harder to compare (visually). Hmmh. I think I see your point here. But Historically, the abixml file wasn't meant to be compared textually. The tool to compare abixml files is abidiff and it knows how to deal with that. > 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. I get that. We try to make this possible as much as we can. We also have other constraints to satisfy. We try to make all these ends meet. Cheers, --=20 Dodji