From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129631 invoked by alias); 10 Jun 2017 00:24:36 -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 129509 invoked by uid 89); 10 Jun 2017 00:24:18 -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=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=consequences X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW 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-it0-f53.google.com Received: from mail-it0-f53.google.com (HELO mail-it0-f53.google.com) (209.85.214.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 10 Jun 2017 00:24:17 +0000 Received: by mail-it0-f53.google.com with SMTP id r63so4623352itc.1 for ; Fri, 09 Jun 2017 17:24:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=v9i2cPFI+9CIN+Oxtrlv7fiztWYseRHaVEn1HA5LxlU=; b=NV7JIeDUwzHVl+vhll/kem2TR0os1Iui27Tn6s7VUhP/giXK69BhErPaUfBcA5UG3H +D8TDVho6WCjQnZHJBF6McwqfWQBHkj+rFP720MviSn4BFhNajLaOCZLLuw2IxqCCPnO txxUkgbwldELQNeiSfrCqcsek5/M/vUNONt/YNroMuQNUCMySYJ23106bL7Wy2i3Ql7E /2CtvwfT1OMB1mHu1cjZcoCWQ25QMVVnoACDBNew+Nt2WnEwhzNlOLsF3NtYvTLhexDU d2Po8727G0YTto7OsNtTRgvx1+kU0OF63yrE8IAiTdMKtXVUYdcnHv2F9sp9PCiacSQB Jjog== X-Gm-Message-State: AODbwcCq1bDrv5FT33RhuS8zLIzJ70EjCh7p+YmSsgJEY1gh3cV5KGFz FgZx3fL5q9CQ2/WXyqG2IJKUKrjJ/yIToiipgA== X-Received: by 10.107.17.21 with SMTP id z21mr33438219ioi.34.1497054250162; Fri, 09 Jun 2017 17:24:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.56.132 with HTTP; Fri, 9 Jun 2017 17:24:09 -0700 (PDT) From: Ben Woodard Date: Sun, 01 Jan 2017 00:00:00 -0000 Message-ID: Subject: inlining change and abidiff noise To: libabigail@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-q2/txt/msg00044.txt.bz2 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. 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. What I would like to know is if that assumption is in fact correct?