Re: [PATCH] x86: conditionalize workaround for build issue with GNU ld 2.37

[Jan Beulich <jbeulich@xxxxxxxx>]

On 13.09.2021 16:33, Roger Pau Monné wrote:
> On Mon, Sep 13, 2021 at 04:05:15PM +0200, Jan Beulich wrote:
>> On 13.09.2021 15:37, Roger Pau Monné wrote:
>>> On Thu, Sep 09, 2021 at 04:35:49PM +0200, Jan Beulich wrote:
>>>> I haven't been able to find an environment where I could actually try
>>>> with lld (ld.lld); all testing was with GNU ld (ld.bfd).
>>>
>>> Thanks for fixing this. I've been able to test with LLVM ld and the
>>> workaround is fine.
>>
>> Oh, good, thanks for trying this out.
>>
>>>> --- a/xen/arch/x86/Makefile
>>>> +++ b/xen/arch/x86/Makefile
>>>> @@ -92,10 +92,16 @@ efi-$(CONFIG_PV_SHIM_EXCLUSIVE) :=
>>>>  
>>>>  ifneq ($(build_id_linker),)
>>>>  notes_phdrs = --notes
>>>> +# Determine whether to engage a workaround for GNU ld 2.37.
>>>> +build-id-ld-good = $(shell echo 'void test(void) {}' \
>>>> +                           | $(CC) $(XEN_CFLAGS) -o .check.o -c -x c - 
>>>> 2>.check.err \
>>>> +                           && $(LD) -T check.lds -o .check.elf .check.o 
>>>> 2>>.check.err \
>>>> +                           && echo y)
>>>
>>> Do we want to make this a Kconfig option (ie: LD_UNQUOTED_DASH) and
>>> then use is here?
>>>
>>> We already have compiler and assembler checks in x86/Kconfig, so it
>>> would seem more natural to place it there.
>>
>> The question of whether to record tool chain capabilities in .config
>> is still pending. I'm not convinced this is a good idea, Andrew keeps
>> shouting me out for that, and an actual discussion doesn't really
>> happen. Yet unlike back at the time when I first raised my concern,
>> Anthony meanwhile supports me in at least the question (to Andrew) of
>> when such a discussion would have happened: Neither of us is aware,
>> yet Andrew claims it did happen, but so far didn't point out where
>> one could read about what was discussed and decided there.
>>
>> For the few uses we've accumulated I gave (if at all) an ack for
>> things happening under some sort of pressure, with the request that
>> aformentioned discussion would happen subsequently (and, depending on
>> outcome, these would be converted to another approach if need be). I
>> have meanwhile realized that it was a mistake to allow such things in
>> on this basis - the more of them we gain, the more I'm hearing "we've
>> already got some".
> 
> I see, that's not an ideal situation from a review PoV, as we don't
> have a clear placement for those and that will just cause confusion
> (and more work since there are potentially two places to check).
> 
> What's the benefit of placing the checks in Kconfig instead of the
> Makefiles?
> 
> As I understand Kconfig is run only once, while the Makefile could run
> the check multiple times.

Right - as many times as a directory would be entered for building,
times the number of evaluations of a respective variable.

> The downfall of having them in .config is that .config could suddenly
> change as tools are updated or as it's moved around different systems
> (yet .config already contains specific compiler version information).

Correct: Tool chain specific information may get updated, but then
further options may get silently turned off. Plus to update tool
chain specific information there needs to be a trigger to invoke
kconfig in the first place. Merely relying on make dependencies is
not enough there. Iirc we don't have any means in place yet to
actually enforce this even when there's no other reason to run
kconfig in the course of re-building a previously built tree.

Jan