From mboxrd@z Thu Jan  1 00:00:00 1970
From: Nathan_Lynch@mentor.com (Nathan Lynch)
Date: Fri, 8 May 2015 10:27:52 -0500
Subject: Bulid regression with VDSO enabled
In-Reply-To: <391d6fc127b78ef4cbc5443557f0665a@agner.ch>
References: <391d6fc127b78ef4cbc5443557f0665a@agner.ch>
Message-ID: <554CD5F8.10901@mentor.com>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

On 05/08/2015 06:13 AM, Stefan Agner wrote:
> On 2015-05-01 17:22, Nathan Lynch wrote:
>> 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.
> 
> This error does not look like the error I have:

I can see I perhaps phrased that badly; when I said I can recreate "this"
I meant I could recreate the issue you reported.  I was intending to
point out that even if the vdso build with gold is fixed or worked
around, the kernel still won't link because gold doesn't implement
--pic-veneer.


> Also, I used the BFD linker by adding LD=${CROSS_COMPILE}ld.bfd to the
> build command. Interestingly thought, I had the same issue when using
> gold linker...

When I try this, ld.gold is used regardless.

You can tell by doing and checking for a NT_GNU_GOLD_VERSION note:

$ readelf -n arch/arm/vdso/vdso.so.raw                            

Displaying notes found at file offset 0x000001bc with length 0x00000040:
  Owner                 Data size       Description
  GNU                  0x00000009       NT_GNU_GOLD_VERSION (gold version)
  GNU                  0x00000014       NT_GNU_BUILD_ID (unique build ID bitstring)
    Build ID: f025409550acb7f955c61d95691291da078e6688