Bulid regression with VDSO enabled

[Nathan_Lynch@mentor.com (Nathan Lynch)]

On 05/09/2015 03:31 AM, Ard Biesheuvel wrote:
> Hi Nathan,
> 
> On 8 May 2015 at 23:15, Nathan Lynch <Nathan_Lynch@mentor.com> wrote:
>> On 05/08/2015 11:08 AM, Stefan Agner wrote:
>>> On 2015-05-08 17:27, Nathan Lynch wrote:
>>>> On 05/08/2015 06:13 AM, Stefan Agner wrote:
>>>>> 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
>>
>> This is just an object file that hasn't been linked, but your general
>> point stands -- LD is honored by other parts of the build.
>>
>>
> 
> I suppose this implies that the build only chokes on --pic-veneer when
> linking the VDSO, and nowhere else?

No, --pic-veneer isn't the problem for the VDSO; for better or worse
LDFLAGS is ignored for the VDSO build.