From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nathan_Lynch@mentor.com (Nathan Lynch) Date: Fri, 1 May 2015 10:22:30 -0500 Subject: Bulid regression with VDSO enabled In-Reply-To: References: <679194be9498c72543073a833e4a1719@agner.ch> <55423E48.7000506@mentor.com> <087d88d067bde8159185670b82357f0a@agner.ch> <55424ED1.9030005@mentor.com> Message-ID: <55439A36.4040801@mentor.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 04/30/2015 10:58 AM, Stefan Agner wrote: > On 2015-04-30 17:48, Nathan Lynch wrote: >> On 04/30/2015 10:20 AM, Stefan Agner wrote: >>> On 2015-04-30 16:38, Nathan Lynch wrote: >>>> On 04/30/2015 06:44 AM, Stefan Agner wrote: >>>>> OBJCOPY arch/arm/vdso/vdso.so >>>>> BFD: arch/arm/vdso/vdso.so: Not enough room for program headers, try >>>>> linking with -N >>>>> arm-angstrom-linux-gnueabi-objcopy:arch/arm/vdso/vdso.so[.hash]: Bad >>>>> value >>>>> BFD: arch/arm/vdso/vdso.so: Not enough room for program headers, try >>>>> linking with -N >>>>> arm-angstrom-linux-gnueabi-objcopy:arch/arm/vdso/vdso.so: Bad value >>>>> make[2]: *** [arch/arm/vdso/vdso.so] Error 1 >>>>> make[1]: *** [arch/arm/vdso] Error 2 >>>>> make[1]: *** Waiting for unfinished jobs.... >>>>> >>>>> I'm using GCC 4.8.3 (Linaro GCC 4.8-2014.04) on Fedora 21. Any specific >>>>> new requirements to the toolchain or a bug? >>>> >>>> I've not encountered this before, and I'm not able to recreate it with >>>> that toolchain. >>>> >>>> If you're using the Linaro toolchain I would expect the name of objcopy >>>> to be arm-linux-gnueabihf-objcopy, but your log shows >>>> arm-angstrom-linux-gnueabi-objcopy. What's going on there? >>> >>> The toolchain is built by the OpenEmbedded build system. I used the >>> Angstrom distribution, which uses the Linaro Layer (daisy branch) which >>> built that toolchain: >>> https://git.linaro.org/openembedded/meta-linaro.git/shortlog/refs/heads/daisy >>> >>> I tried the official release and I also could not reproduce the issue, >>> so it seems to be toolchain related...? >> >> Okay thanks, that gives me more to go on. I probably won't be able to >> devote more time to this today, but hopefully tomorrow. > > FWIW, I just looked into it a bit more myself, however don't understand > what is wrong with that toolchain so far. The generated linker command > looks good for both toolchains, it is really that one linker creates the > problem with the very same arguments while the other does not. > > The toolchain generated by OpenEmbedded is probably quite different from > the official releases. There are a bunch of configurations which are > tweaked depending on the local OE configuration as well: > https://github.com/openembedded/oe-core/blob/master/meta/recipes-devtools/gcc/gcc-configure-common.inc A relevant difference would seem to be that ld defaults to gold for this toolchain: $ arm-angstrom-linux-gnueabi-ld --version GNU gold (GNU Binutils 2.24) 1.11 ... I've not been explicitly testing the vdso code with gold until now, sorry. Is gold a "supported" linker for the ARM kernel these days? If I disable CONFIG_VDSO I encounter this during final link: LD init/built-in.o arm-angstrom-linux-gnueabi-ld: --pic-veneer: unknown option arm-angstrom-linux-gnueabi-ld: use the --help option for usage information I've managed to recreate this locally now, and I'll see what can be done. Commit 378ed3ccd2a0 "x86, vdso: Make the vdso linker script compatible with Gold" looks relevant.