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 5DC72385BF83 for ; Mon, 13 Apr 2020 01:39:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5DC72385BF83 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 librem (deer0x15.wildebeest.org [172.31.17.151]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 1F2E1302BB2F; Mon, 13 Apr 2020 03:39:23 +0200 (CEST) Received: by librem (Postfix, from userid 1000) id 77243C0644; Mon, 13 Apr 2020 03:39:01 +0200 (CEST) Date: Mon, 13 Apr 2020 03:39:01 +0200 From: Mark Wielaard To: Dodji Seketeli Cc: libabigail@sourceware.org Subject: Re: How to drop all non-global/defined function declarations? Message-ID: <20200413013901.GA3584@wildebeest.org> References: <20200405200818.GA16021@wildebeest.org> <86d08jprem.fsf@seketeli.org> <46b50532fef132b14a8ee37089616f328d0af210.camel@klomp.org> <86blnzohf5.fsf@seketeli.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86blnzohf5.fsf@seketeli.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-8.9 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: Mon, 13 Apr 2020 01:39:26 -0000 Hi Dodji, On Fri, Apr 10, 2020 at 10:48:14AM +0200, Dodji Seketeli wrote: > Mark Wielaard a écrit: > > 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. I have a patch to get rid of them for the dwarf reader and abidw. Which can be extended to the xml reader and other tools if userful. > > 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. You are right too. I hadn't considered abicompat. It is certainly useful (and necessary) in the case. > > 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. I'll sent a patch for abidw --drop-undefined-syms which should help my case. Cheers, Mark