On Fri, Mar 11, 2022 at 03:55:57PM +0100, Jan Beulich wrote:
> On 11.03.2022 15:34, Roger Pau Monné wrote:
> > On Fri, Mar 11, 2022 at 02:28:40PM +0100, Jan Beulich wrote:
> >> Support for this construct was added in 2.22 only. Avoid the need to
> >> introduce logic to probe for linker script capabilities by (ab)using the
> >> probe for a command line option having appeared at about the same time.
> >>
> >> Fixes: 4b7fd8153ddf ("x86: fold sections in final binaries")
> >> Signed-off-by: Jan Beulich <[email protected]>
> >> ---
> >> v2: Always define HAVE_LD_SORT_BY_INIT_PRIORITY when using LLVM ld.
> >>
> >> --- a/xen/arch/x86/arch.mk
> >> +++ b/xen/arch/x86/arch.mk
> >> @@ -73,6 +73,16 @@ ifeq ($(CONFIG_UBSAN),y)
> >> $(call cc-option-add,CFLAGS_UBSAN,CC,-fno-sanitize=alignment)
> >> endif
> >>
> >> +ifeq ($(call success,$(LD) --version | head -n 1 | grep -q "GNU ld"),y)
> >
> > You are not going to like this, but I think this should live in
> > xen/Kconfig together with CC_IS_{GCC,CLANG}, ie: LD_IS_GNU or similar.
> >
> > It's possible we will need this in the future in other places, so
> > having it in Kconfig makes sense.
>
> Despite me not liking this (until, as said elsewhere, we've properly
> settled on either approach) I did actually consider doing like you
> suggest. But: I would have to introduce there more than I need here,
> just for consistency's sake, and I wouldn't have a way to test the
> LLD part of it (I did check - none of the distros where I chose to
> install Clang offer the linker). I realize I could ask you to help
> with the testing, but then the first point would remain. I'd prefer
> if for this simple build fix it was okay to go the old fashioned
> route ...
I would be fine with you just introducing LD_IS_GNU. That's all we
need so far. We can introduce LD_IS_LLVM if/when required. I prefer
that asymmetry rather than doing the detection here.
Thanks, Roger.
