From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65136 invoked by alias); 15 Jun 2017 12:25:09 -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 63822 invoked by uid 89); 15 Jun 2017 12:25:08 -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=artificially, analyzed, challenges, her 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; Thu, 15 Jun 2017 12:25:05 +0000 Received: from localhost (torimasen.com [88.120.68.215]) by ms.seketeli.net (Postfix) with ESMTPSA id 6A54E236005E; Thu, 15 Jun 2017 14:25:08 +0200 (CEST) Received: by localhost (Postfix, from userid 1000) id EEC9D180C3F5; Thu, 15 Jun 2017 14:25:06 +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: X-Operating-System: Red Hat Enterprise Linux Workstation 7.3 X-URL: http://www.seketeli.net/~dodji Date: Sun, 01 Jan 2017 00:00:00 -0000 In-Reply-To: (Ben Woodard's message of "Fri, 9 Jun 2017 17:24:09 -0700") Message-ID: <87mv99fnfh.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/msg00062.txt.bz2 Hello Ben, Ben Woodard a =C3=A9crit: > One of the challenges doing inter-compiler comparison between object > files created by different compilers is that the signal to noise ratio > is very high apparently due to different inlining decisions. > > Would there be any negative consequences to having abidiff consider > changes which appear to be due to just differences in how the > compilers choose to inline functions. > > As a case in point: > > $ ./tools/abidiff ./tools/.libs/abidiff ../build-llvl/tools/.libs/abidiff > Functions changes summary: 4 Removed, 0 Changed, 0 Added functions > Variables changes summary: 0 Removed, 0 Changed, 0 Added variable > Function symbols changes summary: 7 Removed, 223 Added function > symbols not referenced by debug info > Variable symbols changes summary: 0 Removed, 3 Added variable symbols > not referenced by debug info > > when you look 3 out of 4 of the removed functions and all 233 of the > added functions you can quickly see that they are all weak symbols. A weak symbol is not necessarily a symbol that results from function inlining. A user can very well write in her code: int __attribute__((weak)) power2(int x); And the symbol of that function 'power2' is going to be weak. In this case, however, abidiff is saying that:=20 > Function symbols changes summary: 7 Removed, 223 Added function symbo= ls not referenced by debug info 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. 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. In this case of binaries generated by different compilers, I guess it's different, especially after you've analyzed the changes as you did. 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. > 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. I think that assumption is not correct, unfortunately. A removed weak symbol can result from a using removing the declaration below from the code: int __attribute__((weak)) power2(int x); So doing this by default might lead us to miss some real problems. Maybe we could add a --no-weak-symbols option to abidiff that would implement the logic you are talking about? That way, people who know what they are doing, like yourself, would use it. Then, we'd write a guide for people analysing ABI changes that are due to using different compilers. That guide would introduce the subtleties we are talking about here and mention the abidiff options that need to be used, when and why. What do you think? --=20 Dodji