From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17759 invoked by alias); 19 Jun 2017 08:47:54 -0000 Mailing-List: contact libabigail-help@sourceware.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Id: List-Subscribe: Sender: libabigail-owner@sourceware.org Received: (qmail 17737 invoked by uid 89); 19 Jun 2017 08:47:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=originated, H*r:1001, her, artificially X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: ms.seketeli.net Received: from seketeli.net (HELO ms.seketeli.net) (94.23.218.202) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 19 Jun 2017 08:47:50 +0000 Received: from localhost (torimasen.com [88.120.68.215]) by ms.seketeli.net (Postfix) with ESMTPSA id 3288D236005D; Mon, 19 Jun 2017 10:47:53 +0200 (CEST) Received: by localhost (Postfix, from userid 1001) id 7C8A01A05D1; Mon, 19 Jun 2017 10:47:51 +0200 (CEST) From: Dodji Seketeli To: Ben Woodard Cc: libabigail@sourceware.org Subject: Re: inlining change and abidiff noise Organization: Me, myself and I References: <87mv99fnfh.fsf@seketeli.org> <78E49230-1B78-43CE-A643-63AC1039F694@redhat.com> X-Operating-System: Red Hat Enterprise Linux Server 7.3 X-URL: http://www.seketeli.net/~dodji Date: Sun, 01 Jan 2017 00:00:00 -0000 In-Reply-To: <78E49230-1B78-43CE-A643-63AC1039F694@redhat.com> (Ben Woodard's message of "Fri, 16 Jun 2017 14:57:00 -0700") Message-ID: <86bmpkfjns.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-IsSubscribed: yes X-SW-Source: 2017-q2/txt/msg00066.txt.bz2 Ben Woodard a =C3=A9crit: [...} >> A user can very well write in her code: >>=20 >> int __attribute__((weak)) power2(int x); > > in addition to a declaration like that, wouldn=E2=80=99t there also need = to be > a definition somewhere? Yes. You are right. What I wanted to say is that only the declaration needs to have the weak attribute. But anyway, that's a detail. My point was that a user can willingly decide that a function is going to be generated as a weak symbol. And that would have nothing to do with inlining. [...] >> And the symbol of that function 'power2' is going to be weak. >>=20 >>=20 >> In this case, however, abidiff is saying that:=20 >>=20 >>> Function symbols changes summary: 7 Removed, 223 Added function symbols= not referenced by debug info >>=20 >> In other words, it is saying that the symbols that got added/removed >> match *no* debug info. That is to say that no function explicitely >> written by the user generated those ELF symbols. It follows that those >> symbols result from functions that were generated artificially by the >> compiler. >>=20 >> If this change was happening between two binaries generated with the >> same compiler (and using the same compiler option), it would certainly >> be a hint of a problem. >>=20 > What if the compiler version changes and the decision about which > functions change? Sorry, I don't understand what you mean by 'and the decision about which functions change'. > I would also argue that at least for most compiler option changes like > changing -O level it shouldn=E2=80=99t create any ABI artifacts and nor s= hould > libabigail generate any false positives if you simply change the > optimization level. I agree. The same source code compiled with two different versions of the = same compiler should yield the same ABI. And *generally*, changing optimization options should not incur any ABI change either. > I would argue that the inter-compiler test is just a more rigorous > test of the changes that happen when the optimization level changes. In theory, maybe. In theory, what you say would be a cool assertion that would allow users to mix objects coming from different compilers. But in practise, I disagree. Right now, I think ABI changes between two binaries compiled with different compilers (i.e, clang++ and g++) are not *necessarily* of the same nature as ABI changes between two binaries compiled with the same compiler but with different optimization levels. You seem to think that "WEAK symbols are necessarily related to inlining", roughly. And inlining is impacted by optimization level. And thus, it would follow that if two different compilers incur ABI changes related to WEAK symbols, then these changes are of the same nature as inlining changes and so as optimization level changes. But the problem is that a WEAK symbols are not necessarily related to inlining. [...] >> In this case of binaries generated by different compilers, I guess it's >> different, especially after you've analyzed the changes as you did. >>=20 >> So in this case, you could have used the --no-unreferenced-symbols >> option of abidiff to tell it to avoid showing you changes on symbols for >> which there is no debug info. > > I think that is a bit of a big hammer. I think that in the example you > give below... >>=20 >>> The assumption that I'm making is that adding logic like: >>> if a symbol is added or removed and the only reference to it is with a >>> weak symbol then it is a result of a change in inlining and it is >>> therefore harmless. >>=20 >> I think that assumption is not correct, unfortunately. A removed weak >> symbol can result from a using removing the declaration below from the >> code: >>=20 >> int __attribute__((weak)) power2(int x); > > Would a declaration without a definition generate anything at all?=20 No. But a declaration, followed by definition (that doesn't have the weak attribute) would generate it. And in that case, just removing the weak attribute from the declaration would generate the ABI change. In other words, a *source code change* would very well generate an ABI change in which a WEAK symbol is added or removed. > Isn=E2=80=99t the unique characteristic in this case that we can filter o= n the > fact that we have weak symbols with no DWARF. This characteristic is narrower (and hence, I think, better) than the one you expressed initially, which was (I quote from your initial message): The assumption that I'm making is that adding logic like: if a symbol is added or removed and the only reference to it is with a weak symbol then it is a result of a change in inlining and it is therefore harmless. In that initial assumption, I didn't understand that you meant there was no DWARF describing the function the symbol originated from. So yes, if there is no DWARF describing the function which the WEAK symbol originates from, (which implies that there is no function declaration accompanying the code related to the WEAK symbol), then the probability is higher than the WEAK symbol was artificially generated by the compiler. Note, however, that the user could have written assembly code, inline in his C or C++ source code as well. And that would have resulted into an ELF symbol not described by any DWARF. And even if the code related to the WEAK ELF symbol was indeed artificially generated by the compiler, nothing assures us that it was related to inlining. In other words, I still think that we should rather provide the user with options to filter out, for instance, "unreferenced weak symbols", rather than filtering them by default. Because otherwise, we might hide real problems, by default. Cheers, --=20 Dodji