Bulid regression with VDSO enabled

[Stefan Agner]

On 2015-05-08 17:27, Nathan Lynch wrote:
> 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

Hm, you are right. When deleting moving ld.bfd to ld, which makes the
BFD linker as default, compiling works flawless.

However, so far LD=${CROSS_COMPILE}ld.bfc seems to work for other build
objects, at least those do not have this note. For instance time.o does
not return anything:

$ readelf -n arch/arm/kernel/time.o

So it seems to be a vdso.so.raw specific problem not using the specified
linker...?

--
Stefan