From patchwork Fri Mar 18 09:04:37 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 64047 Delivered-To: patch@linaro.org Received: by 10.112.199.169 with SMTP id jl9csp930524lbc; Fri, 18 Mar 2016 02:04:54 -0700 (PDT) X-Received: by 10.66.118.108 with SMTP id kl12mr19693866pab.151.1458291894219; Fri, 18 Mar 2016 02:04:54 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id qo2si2065049pac.229.2016.03.18.02.04.53; Fri, 18 Mar 2016 02:04:54 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dkim=pass header.i=@linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754680AbcCRJEw (ORCPT + 30 others); Fri, 18 Mar 2016 05:04:52 -0400 Received: from mail-wm0-f54.google.com ([74.125.82.54]:38359 "EHLO mail-wm0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752059AbcCRJEn (ORCPT ); Fri, 18 Mar 2016 05:04:43 -0400 Received: by mail-wm0-f54.google.com with SMTP id l68so27394561wml.1 for ; Fri, 18 Mar 2016 02:04:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=yt3NpkHLBLsLi21PmfPISC+ScjenU8ndCV90il03MJ4=; b=GwU9gG0jOsrO2VsUPRKPWzBx2GG9B5D3pIbH0QZOfaIQ/liEPHExqW+guqa9ATiJ0N CqmmuhV7YpAZ4erkjvhj1FTr5goA9D8HhHqC2tVye+vcv5Wn4QTctNQVNO+uGob0+hAu G0kILGejPd5FWHwbw3FMtOvjH2awWZnhBQBek= 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; bh=yt3NpkHLBLsLi21PmfPISC+ScjenU8ndCV90il03MJ4=; b=g3RIDfeS+VzovycSIwQ3DY9VbQyHa/+p6HmI7YUmfVC8mtXbpG8YYoqrocnZy1ulE8 tfm31xMXVazc0gLcHMgmgSp99/i6IiXymIEcL4sgV5Uhw22RJF8hhM9l/Ep5e4oXvgxR h5krypq74cFz2EaMf/pp91m8anfn9VderH+o1OmZk5zyfyl55zV4/1qboiOuvF9pVsvp 5Re+rv/iDF+wUgZOOVn7yCikHyP1i3jk6MhNuWynD7U/WexZbUrw8/VBGL2IyRY95X+i mNHdws5gcS0rsd+gkOLxh7jpcJPjcag8qbjNY4CAzyb6vEBCinGKqbZ59/Cfqy/k+7sv djnA== X-Gm-Message-State: AD7BkJKbxh/TjOhnzWkRXtf27anJi8Ki8auDznKa1to8O0KzO7PIfk8FeWQKe1qvL2DzrQGk X-Received: by 10.194.203.5 with SMTP id km5mr16277657wjc.172.1458291882164; Fri, 18 Mar 2016 02:04:42 -0700 (PDT) Received: from localhost.localdomain ([195.55.142.58]) by smtp.gmail.com with ESMTPSA id i5sm11271078wja.23.2016.03.18.02.04.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 18 Mar 2016 02:04:41 -0700 (PDT) From: Ard Biesheuvel To: linux-kernel@vger.kernel.org, torvalds@linux-foundation.org, akpm@linux-foundation.org, x86@kernel.org, hpa@zytor.com, rusty@rustcorp.com.au Cc: Ard Biesheuvel Subject: [PATCH] x86/kallsyms: fix GOLD link failure with new relative kallsyms table format Date: Fri, 18 Mar 2016 10:04:37 +0100 Message-Id: <1458291877-26313-1-git-send-email-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.5.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit 2213e9a66bb8 ("kallsyms: add support for relative offsets in kallsyms address table") changed the default kallsyms symbol table format to use relative references rather than absolute addresses. This reduces the size of the kallsyms symbol table by 50% on 64-bit architectures, and further reduces the size of the relocation tables used by relocatable kernels. Since the memory footprint of the static kernel image is always much smaller than 4 GB, these relative references are assumed to be representable in 32 bits, even when the native word size is 64 bits. On 64-bit architectures, this obviously only works if the distance between each relative reference and the chosen anchor point is representable in 32 bits, and so the table generation code in scripts/kallsyms.c scans the table for the lowest value that is covered by the kernel text, and selects it as the anchor point. However, when using the GOLD linker rather than the default BFD linker to build the x86_64 kernel, the symbol phys_offset_64, which is the result of arithmetic defined in the linker script, is emitted as a 'T' rather than an 'A' type symbol, resulting in scripts/kallsyms.c to mistake it for a suitable anchor point, even though it is far away from the actual kernel image in the virtual address space. This results in out-of-range warnings from scripts/kallsyms.c and a broken build. So let's align with the BFD linker, and emit the phys_offset_[32|64] symbols as absolute symbols explicitly. Note that the out of range issue does not exist on 32-bit x86, but this patch changes both symbols for symmetry. Signed-off-by: Ard Biesheuvel --- arch/x86/kernel/vmlinux.lds.S | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) -- 2.5.0 Reported-by: Markus Trippelsdorf diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S index 5af9958cbdb6..6bb070e54fda 100644 --- a/arch/x86/kernel/vmlinux.lds.S +++ b/arch/x86/kernel/vmlinux.lds.S @@ -81,11 +81,11 @@ PHDRS { SECTIONS { #ifdef CONFIG_X86_32 - . = LOAD_OFFSET + LOAD_PHYSICAL_ADDR; - phys_startup_32 = startup_32 - LOAD_OFFSET; + . = LOAD_OFFSET + LOAD_PHYSICAL_ADDR; + phys_startup_32 = ABSOLUTE(startup_32 - LOAD_OFFSET); #else - . = __START_KERNEL; - phys_startup_64 = startup_64 - LOAD_OFFSET; + . = __START_KERNEL; + phys_startup_64 = ABSOLUTE(startup_64 - LOAD_OFFSET); #endif /* Text and read-only data */