On Mon, Mar 14, 2022 at 08:38:52AM +0100, Jan Beulich wrote:
> On 11.03.2022 16:07, Roger Pau Monné wrote:
> > 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.
>
> Yet I'm not happy to go this route. I'm only willing to do this
> consistently, but that in turn not without us having formally sat down
> and discussed the overall model to use. The only short term alternative
> I see is to go back to SORT() unilaterally, hoping that for now
> different priorities won't be encountered.
Would you be fine if it was a patch of mine that introduces
LD_IS_{GNU,LLVM} to xen/Kconfig (Acked by someone else) and then you
use it here?
I realize this is tricking you, but I would rather get this unblocked
if possible.
While I can agree to test for features in Makefiles closer to the
place where they are used, I don't like doing the version checks in
Makefiles, much less arch-specific ones.
Thanks, Roger.
