From patchwork Wed Nov 23 16:41:37 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nicholas Piggin X-Patchwork-Id: 9443775 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 317316075F for ; Wed, 23 Nov 2016 16:42:08 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 39AAA27B81 for ; Wed, 23 Nov 2016 16:42:08 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 2E51D27C0C; Wed, 23 Nov 2016 16:42:08 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B056B27B81 for ; Wed, 23 Nov 2016 16:42:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934414AbcKWQmG (ORCPT ); Wed, 23 Nov 2016 11:42:06 -0500 Received: from mail-pf0-f195.google.com ([209.85.192.195]:33145 "EHLO mail-pf0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933872AbcKWQmE (ORCPT ); Wed, 23 Nov 2016 11:42:04 -0500 Received: by mail-pf0-f195.google.com with SMTP id 144so865538pfv.0 for ; Wed, 23 Nov 2016 08:42:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=1nv4NNE1C98qGPg5opWLgTH9i2oWKyTnjsiWV645iZw=; b=PtuRlEnVSa1J7/niRbwCsblR7VpO9hq4GtpiKtlEvFTN+P1ulqFXPp38jvfYobtr8I mSlsh7lcbLIOvCrWFkF14BWzf8zDlpwdcN8NPiOhckrVx4DZFgBeQpFa/wglrn/DXvYj mEpHig4UfD20TkgpPsS2Dg4b1l9DSyAs4+AsgNGvVfFraUwOVdLexkxN3eBAhhegaoiX QZYuYGRbLLbyq4emxrbp6/kgizVa1V4VnPEMXIcJ+hqIszCiuenXQTyrEGjBtK8CGzYi f5dK3scRsNCThADtt8X/gOLefJN3tWJzssPVx54LRNp40FBC4oWvYCBIdef6muwG6VYl PVeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=1nv4NNE1C98qGPg5opWLgTH9i2oWKyTnjsiWV645iZw=; b=M0jebWHdBVqNQAw8RhOcAH8ZGY3pbgkn/09zTWLN9iR6FiaRhgN/zIY0Q8tpUd6hyu FzXDqgdfQ2aPUZCcghyDbizKiByfxhChYHOWUspBLzWNlisVCBqNMlXNVDrt1cs+kP5G OPrDxaNlvDrAHH7VKD6dCcrERL2NcnEf2CXMjH0YhDsXRSn2q5Oz8EPT6mEXusmhVDWE c866X9ncjVKKEQ+w00/ubQrAJIDEcxQPJfVCt6VUE9KjBCzxMLYWEd2IUpV5gY5cCDMO rZiCb/rLW1n/1lxlAi2o+jK/HzzwMIHQug0KuCr67QCmm64P1SQQICytNwhvcL5VWEHx K00Q== X-Gm-Message-State: AKaTC03kEMExoxvr0a1XvL8Qz/oTGA4AqtsQaBEV5T0RuIOHCmx0jR38RoWUylT7+Y6qqg== X-Received: by 10.84.128.195 with SMTP id a61mr8384720pla.55.1479919323613; Wed, 23 Nov 2016 08:42:03 -0800 (PST) Received: from roar.au.ibm.com (27-33-21-189.tpgi.com.au. [27.33.21.189]) by smtp.gmail.com with ESMTPSA id o26sm53959762pfk.91.2016.11.23.08.42.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Nov 2016 08:42:02 -0800 (PST) From: Nicholas Piggin To: Michal Marek Cc: Nicholas Piggin , linux-kbuild@vger.kernel.org Subject: [PATCH 1/7] kbuild: kallsyms allow 3-pass generation if symbols size has changed Date: Thu, 24 Nov 2016 03:41:37 +1100 Message-Id: <20161123164143.16839-2-npiggin@gmail.com> X-Mailer: git-send-email 2.10.2 In-Reply-To: <20161123164143.16839-1-npiggin@gmail.com> References: <20161123164143.16839-1-npiggin@gmail.com> Sender: linux-kbuild-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kbuild@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP kallsyms generation is not foolproof, due to some linkers adding symbols (e.g., branch trampolines) when a binary size changes. Have it attempt a 3rd pass automatically if the kallsyms size changes in the 2nd pass. This allows powerpc64 allyesconfig to build without adding another pass when it's not required. This can be solved other ways by directing the linker not to add labels on branch stubs, or to move kallsyms near the end of the image. The former is undesirable for debugging/tracing, and the latter is a more significant change that requires more testing and review. Signed-off-by: Nicholas Piggin --- scripts/link-vmlinux.sh | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh index f742c65..6b94fe4 100755 --- a/scripts/link-vmlinux.sh +++ b/scripts/link-vmlinux.sh @@ -246,10 +246,14 @@ if [ -n "${CONFIG_KALLSYMS}" ]; then # the right size, but due to the added section, some # addresses have shifted. # From here, we generate a correct .tmp_kallsyms2.o - # 2a) We may use an extra pass as this has been necessary to - # woraround some alignment related bugs. - # KALLSYMS_EXTRA_PASS=1 is used to trigger this. - # 3) The correct ${kallsymso} is linked into the final vmlinux. + # 3) That link may have expanded the kernel image enough that + # more linker branch stubs / trampolines had to be added, which + # introduces new names, which further expands kallsyms. Do another + # pass if that is the case. In theory it's possible this results + # in even more stubs, but unlikely. + # KALLSYMS_EXTRA_PASS=1 may also used to debug or work around + # other bugs. + # 4) The correct ${kallsymso} is linked into the final vmlinux. # # a) Verify that the System.map from vmlinux matches the map from # ${kallsymso}. @@ -265,8 +269,11 @@ if [ -n "${CONFIG_KALLSYMS}" ]; then vmlinux_link .tmp_kallsyms1.o .tmp_vmlinux2 kallsyms .tmp_vmlinux2 .tmp_kallsyms2.o - # step 2a - if [ -n "${KALLSYMS_EXTRA_PASS}" ]; then + # step 3 + size1=$(stat -c "%s" .tmp_kallsyms1.o) + size2=$(stat -c "%s" .tmp_kallsyms2.o) + + if [ $size1 -ne $size2 ] || [ -n "${KALLSYMS_EXTRA_PASS}" ]; then kallsymso=.tmp_kallsyms3.o kallsyms_vmlinux=.tmp_vmlinux3