Re: [PATCH v3 2/3] XENVER_build_id: Provide ld-embedded build-ids (v8)

[Konrad Rzeszutek Wilk <konrad@kernel.org>]

>>> Wouldn't it be better to probe the linker for recognizing the --build-id
>>> command line option, along the lines of $(cc-option)?
>>
>> +ld-ver-build-id = $(shell $(1) --build-id 2>&1 | \
>> +                                       grep -q unrecognized && echo n
>> || echo y)
>>
>> -ish ?
>
> If that fulfills the purpose - why not?

Great. Will use that (after checking it on on SLES10).
>
>>> In any event the option should be added to LDFLAGS unless this
>>> conflicts with something else.
>>
>> That had some interesting side-effect:
>>
>> $ find . -name *.o | xargs readelf -n | more
>> File: ./arch/x86/built_in.o
>>
>> Displaying notes found at file offset 0x00000040 with length 0x00000240:
>>   Owner                 Data size       Description
>>   GNU                  0x00000014       NT_GNU_BUILD_ID (unique build
>> ID bitstring)
>>     Build ID: a114d1fdec2ace38448f141013f5a659122f2390
>>   GNU                  0x00000014       NT_GNU_BUILD_ID (unique build
>> ID bitstring)
.. snip..
>> And during build:
>> ld: warning: Cannot create .note.gnu.build-id section, --build-id ignored.
.. snip..
>> I think we should skip on the LDFLAGS idea.
>
> Isn't that merely a result of LDFLAGS being used for both the
> linking of the various built_in.o and the final binaries? A fully

True.
> shared set of flags for these two pretty distinct operations
> doesn't seem very sensible anyway. In fact I wonder how
> much of LDFLAGS is actually relevant when passing -r to ld.
>

That would imply that the idea of putting --build-id should be part
only of the final binaries. Which comes back to how this patch was done
originally - only have the --build-id on specific $(LD) lines.

Are you OK if I re-institute the $(build_id) back in the Makefile, perhaps
rename it to $(build_id_linker) to make it more clear?

Thanks.