Bulid regression with VDSO enabled

[Nathan Lynch]

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.