From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17248 invoked by alias); 16 Jun 2017 22:03:55 -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 17229 invoked by uid 89); 16 Jun 2017 22:03:54 -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: =?ISO-8859-1?Q?No, score=-1.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=wouldn, wouldn=e2, her, artificially?= X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE 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: mail-pf0-f175.google.com Received: from mail-pf0-f175.google.com (HELO mail-pf0-f175.google.com) (209.85.192.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 16 Jun 2017 22:03:53 +0000 Received: by mail-pf0-f175.google.com with SMTP id 83so27991278pfr.0 for ; Fri, 16 Jun 2017 15:03:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=d3ETgBbyyl1rrDJmpmSETyv6BEMv7rU7ZJ8LtdP14+Y=; b=TrwGa9xIdcMfj2BE628H1AtiOBeAlj+9rgvoQ0Fre3ZauZfQejsH5I9nd+7HGyDmWq tDPkGHWQy3rGt61zbPyIWV9SgoacGKFOdMnkNrVy4Ixhyhkq3ADM9jpIagi47y2JNM43 mpqzgFgh8gj2eAleXM/5WTM1YiQWmr8Dets8hLNvhL57RFTsMh7Tb5LiPsoPqSsxkXII JyZXs91TNoHdPrBbBqFsGWCpKhVM6geQLv4Y2Br/fmEyZJfeop9uOxVMve6T/MFSKiPA 1nA1pvGw98C5fQ9m96qc4C2JXJAZJZ30OV6UlKaQUC8hBPJkFKdEPKwyk27C4lKfrAOl 4X2g== X-Gm-Message-State: AKS2vOxbSbBIvMNq5imZCjNNrEWOJrG57ik3+KRuo6dThUqveYNDUDQX U9pchUEAJMSRrttOArOWeA== X-Received: by 10.98.141.134 with SMTP id p6mr3436888pfk.68.1497650636313; Fri, 16 Jun 2017 15:03:56 -0700 (PDT) Received: from [192.168.1.223] (c-76-102-219-240.hsd1.ca.comcast.net. [76.102.219.240]) by smtp.gmail.com with ESMTPSA id g13sm6166842pgu.54.2017.06.16.15.03.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Jun 2017 15:03:55 -0700 (PDT) From: Ben Woodard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: inlining change and abidiff noise Date: Sun, 01 Jan 2017 00:00:00 -0000 References: <87mv99fnfh.fsf@seketeli.org> To: libabigail@sourceware.org In-Reply-To: <87mv99fnfh.fsf@seketeli.org> Message-Id: X-Mailer: Apple Mail (2.3273) X-IsSubscribed: yes X-SW-Source: 2017-q2/txt/msg00065.txt.bz2 > On Jun 15, 2017, at 5:25 AM, Dodji Seketeli wrote: >=20 > Hello Ben, >=20 > Ben Woodard a =C3=A9crit: >=20 >> 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. >>=20 >> 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. >>=20 >> As a case in point: >>=20 >> $ ./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 >>=20 >> 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. >=20 > A weak symbol is not necessarily a symbol that results from function > inlining. >=20 > 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? >=20 > 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? I would also argue that at least for most compiler option changes like chan= ging -O level it shouldn=E2=80=99t create any ABI artifacts and nor should = libabigail generate any false positives if you simply change the optimizati= on level. I would argue that the inter-compiler test is just a more rigorou= s test of the changes that happen when the optimization level changes. >=20 > 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 > 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. >=20 I think that is a bit of a big hammer. I think that in the example you give= below=E2=80=A6 >> 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); >=20 Would a declaration without a definition generate anything at all?=20 Isn=E2=80=99t the unique characteristic in this case that we can filter on = the fact that we have weak symbols with no DWARF. Is there another example = you can contrive where a CU has DWARF (i.e. it isn=E2=80=99t just stripped = ELF or the result of a compilation without -g) but the compiler generates w= eak symbols that do not have associated DWARF where there is in fact a legi= timate ABI change? > So doing this by default might lead us to miss some real problems. You=E2=80=99re the expert but I=E2=80=99m not completely convinced yet. >=20 > 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. >=20 > 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. >=20 > What do you think? >=20 > --=20 > Dodji