From patchwork Thu Mar 17 15:07:05 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 64007 Delivered-To: patch@linaro.org Received: by 10.112.199.169 with SMTP id jl9csp523789lbc; Thu, 17 Mar 2016 08:07:24 -0700 (PDT) X-Received: by 10.66.146.196 with SMTP id te4mr15531454pab.125.1458227243879; Thu, 17 Mar 2016 08:07:23 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g78si13014069pfd.130.2016.03.17.08.07.23; Thu, 17 Mar 2016 08:07:23 -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=neutral (body hash did not verify) header.i=@linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1031257AbcCQPHJ (ORCPT + 31 others); Thu, 17 Mar 2016 11:07:09 -0400 Received: from mail-ig0-f170.google.com ([209.85.213.170]:35993 "EHLO mail-ig0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934982AbcCQPHG convert rfc822-to-8bit (ORCPT ); Thu, 17 Mar 2016 11:07:06 -0400 Received: by mail-ig0-f170.google.com with SMTP id nk17so123500919igb.1 for ; Thu, 17 Mar 2016 08:07:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=dZoejmXXLXQTaTkdKT8wlHiIGibUvcrEysBEL1kZH7M=; b=MwvJC+xFGqCDxhSWuyyVa1Lg29M4kLUVHNxf3+wrO9yJJvMzk+Su0kX2RJE9T9XXCV fPfm8BSRQIYSv+GC3MfLHt58otYUZWf75mx8UULGg28c7x7zGTAqglopeZD8GnhXM0El LzZEg41TJIMdahmjOAkwKyprF8NpxiCXJfGus= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=dZoejmXXLXQTaTkdKT8wlHiIGibUvcrEysBEL1kZH7M=; b=jGiqnuyQ5CLXER6znLOZIAgihISFBaWXfLcxLro4cDd1wp0BdIkxh3kQSOm3QgiMpn r9zQxKe+jzVUENTlsGh46O34cNhRyOaYa6riI0HYzZ4n8/Sg48Ljqf2QyCA8BBpOGa/5 81l1GLMC/JdrKmW7z1vwqgiSpM9JZXXqcEwsKLWu0rmXJoRmZkJzto0jO8UncMddyqgw Bum8p/qC/iBeSwCzUN5gS99TsiVRIVHHhay/tutvQW0HQxnDfigRXr/j49ENySv+N7WX +n3erhu3B4QoQWtunmbvJjocj+uoj2l1Gtlm+/8dvaYdAKteQxwR32lA0FrSeYi8meIM 1XoA== X-Gm-Message-State: AD7BkJKBMv7RKlGf5Zps9rFEqFm7iE+gqLxp5KHLIr77hwgxB8C/51f+q2323Q24vCAr9CJgyNXdB0EKYU1br+7T MIME-Version: 1.0 X-Received: by 10.50.73.229 with SMTP id o5mr11351285igv.75.1458227225631; Thu, 17 Mar 2016 08:07:05 -0700 (PDT) Received: by 10.36.29.6 with HTTP; Thu, 17 Mar 2016 08:07:05 -0700 (PDT) In-Reply-To: References: <20160316212517.GA309@x4> <20160317071424.GA310@x4> Date: Thu, 17 Mar 2016 16:07:05 +0100 Message-ID: Subject: Re: kallsyms failure: relative symbol value 0xffffffff810002a0 out of range in relative mode From: Ard Biesheuvel To: Markus Trippelsdorf Cc: Guenter Roeck , Kees Cook , Heiko Carstens , Michael Ellerman , Ingo Molnar , "H. Peter Anvin" , Benjamin Herrenschmidt , Michal Marek , Rusty Russell , Arnd Bergmann , Andrew Morton , Linus Torvalds , "linux-kernel@vger.kernel.org" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 17 March 2016 at 12:17, Ard Biesheuvel wrote: > On 17 March 2016 at 12:01, Ard Biesheuvel wrote: >> On 17 March 2016 at 08:14, Markus Trippelsdorf wrote: >>> On 2016.03.17 at 08:03 +0100, Ard Biesheuvel wrote: >>>> On 16 March 2016 at 22:25, Markus Trippelsdorf wrote: >>>> > Since: >>>> > commit 2213e9a66bb87d8344a1256b4ef568220d9587fb >>>> > Author: Ard Biesheuvel >>>> > Date: Tue Mar 15 14:58:19 2016 -0700 >>>> > >>>> > kallsyms: add support for relative offsets in kallsyms address table >>>> > >>>> > kernels linked with ld.gold are broken: >>>> > >>>> >>>> Could you elaborate? I tried building x86_64_defconfig with >>>> -fuse-ld=gold added to LDFLAGS, and it builds fine. >>>> >>>> Could you share your config, please? And instructions how to invoke >>>> the gold linker? >>> >>> I'm using gold trunk and ld.gold is my system linker (just a hard link >>> to ld). My config is attached. >>> >>> (For testing I use the following qemu command: >>> qemu-system-x86_64 -s -enable-kvm -net nic,vlan=0,model=virtio -net user -fsdev local,security_model=none,id=root,path=/ -device virtio-9p-pci,id=root,fsdev=root,mount_tag=/dev/root -m 512 -smp 2 -kernel /usr/src/linux/arch/x86/boot/bzImage -nographic -append "init=/bin/zsh root=/dev/root console=ttyS0 kgdboc=ttyS0 rootflags=rw,trans=virtio rootfstype=9p ip=dhcp earlyprintk=ttyS0" ) >>> >>>> > KSYM .tmp_kallsyms1.o >>>> > kallsyms failure: relative symbol value 0xffffffff810002a0 out of range in relative mode >>>> > KSYM .tmp_kallsyms2.o >>>> > kallsyms failure: relative symbol value 0xffffffff810002a0 out of range in relative mode >>>> > LD vmlinux >>>> > >>>> > They die early during boot: >>>> > >>>> >>>> Note that there is a patch queued in the kbuild tree to at least abort >>>> the build if such failures happens. >>> >>> Yes. That would be much better. >>> >> >> I tried building with your config, and I still cannot reproduce. I >> using my system's GCC + GOLD: >> >> gold -v >> GNU gold (GNU Binutils for Ubuntu 2.25.1) 1.11 >> >> Using built-in specs. >> COLLECT_GCC=gcc >> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper >> Target: x86_64-linux-gnu >> Configured with: ../src/configure -v --with-pkgversion='Ubuntu >> 5.2.1-22ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs >> --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ >> --prefix=/usr --program-suffix=-5 --enable-shared >> --enable-linker-build-id --libexecdir=/usr/lib >> --without-included-gettext --enable-threads=posix --libdir=/usr/lib >> --enable-nls --with-sysroot=/ --enable-clocale=gnu >> --enable-libstdcxx-debug --enable-libstdcxx-time=yes >> --with-default-libstdcxx-abi=new --enable-gnu-unique-object >> --disable-vtable-verify --enable-libmpx --enable-plugin >> --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk >> --enable-gtk-cairo >> --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre >> --enable-java-home >> --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 >> --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 >> --with-arch-directory=amd64 >> --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc >> --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 >> --with-multilib-list=m32,m64,mx32 --enable-multilib >> --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu >> --host=x86_64-linux-gnu --target=x86_64-linux-gnu >> Thread model: posix >> gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2) >> >> Can you reproduce it with a release version of GOLD? > > Actually, I managed to reproduce it by updating my system's > /usr/bin/ld symlink to point to ld.gold. > > Looking into it now ... The following patch fixes things for me: The problem appears to be that GOLD emits a 'T' type symbol for phys_startup_64, while ld.bfd treats this as an absolute quantity (which kallsyms ignores). Since this symbol has no meaning to the kernel itself when it runs from its virtual offset, forcing it to absolute is probably the simplest approach. If anyone disagrees, let me know. Otherwise, I will fold this into a proper patch and send it out tomorrow. -- Ard. diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S index 5af9958cbdb6..aa7a0cbd1d2e 100644 --- a/arch/x86/kernel/vmlinux.lds.S +++ b/arch/x86/kernel/vmlinux.lds.S @@ -82,10 +82,10 @@ SECTIONS { #ifdef CONFIG_X86_32 . = LOAD_OFFSET + LOAD_PHYSICAL_ADDR; - phys_startup_32 = startup_32 - LOAD_OFFSET; + phys_startup_32 = ABSOLUTE(startup_32 - LOAD_OFFSET); #else . = __START_KERNEL; - phys_startup_64 = startup_64 - LOAD_OFFSET; + phys_startup_64 = ABSOLUTE(startup_64 - LOAD_OFFSET); #endif /* Text and read-only data */