All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] x86: avoid SORT_BY_INIT_PRIORITY with old GNU ld
@ 2022-03-07 13:49 Jan Beulich
  2022-03-07 15:05 ` Roger Pau Monné
  0 siblings, 1 reply; 7+ messages in thread
From: Jan Beulich @ 2022-03-07 13:49 UTC (permalink / raw)
  To: xen-devel; +Cc: Andrew Cooper, Wei Liu, Roger Pau Monné

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 <jbeulich@suse.com>
---
Obviously this doesn't take care of old LLVM ld yet, if any care is
needed there in the first place.

--- a/xen/arch/x86/arch.mk
+++ b/xen/arch/x86/arch.mk
@@ -70,6 +70,11 @@ ifeq ($(CONFIG_UBSAN),y)
 $(call cc-option-add,CFLAGS_UBSAN,CC,-fno-sanitize=alignment)
 endif
 
+# While not much better than going by raw GNU ld version, utilize that the
+# feature we're after has appeared in the same release as the
+# --print-output-format command line option.
+AFLAGS-$(call ld-option,--print-output-format) += -DHAVE_LD_SORT_BY_INIT_PRIORITY
+
 ifneq ($(CONFIG_PV_SHIM_EXCLUSIVE),y)
 
 efi-check := arch/x86/efi/check
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -30,6 +30,10 @@ ENTRY(start_pa)
 # define SECTION_ALIGN PAGE_SIZE
 #endif
 
+#ifndef HAVE_LD_SORT_BY_INIT_PRIORITY
+# define SORT_BY_INIT_PRIORITY SORT
+#endif
+
 OUTPUT_FORMAT(FORMAT, FORMAT, FORMAT)
 
 OUTPUT_ARCH(i386:x86-64)



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] x86: avoid SORT_BY_INIT_PRIORITY with old GNU ld
  2022-03-07 13:49 [PATCH] x86: avoid SORT_BY_INIT_PRIORITY with old GNU ld Jan Beulich
@ 2022-03-07 15:05 ` Roger Pau Monné
  2022-03-07 15:29   ` Jan Beulich
  0 siblings, 1 reply; 7+ messages in thread
From: Roger Pau Monné @ 2022-03-07 15:05 UTC (permalink / raw)
  To: Jan Beulich; +Cc: xen-devel, Andrew Cooper, Wei Liu

On Mon, Mar 07, 2022 at 02:49:32PM +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 <jbeulich@suse.com>
> ---
> Obviously this doesn't take care of old LLVM ld yet, if any care is
> needed there in the first place.
> 
> --- a/xen/arch/x86/arch.mk
> +++ b/xen/arch/x86/arch.mk
> @@ -70,6 +70,11 @@ ifeq ($(CONFIG_UBSAN),y)
>  $(call cc-option-add,CFLAGS_UBSAN,CC,-fno-sanitize=alignment)
>  endif
>  
> +# While not much better than going by raw GNU ld version, utilize that the
> +# feature we're after has appeared in the same release as the
> +# --print-output-format command line option.
> +AFLAGS-$(call ld-option,--print-output-format) += -DHAVE_LD_SORT_BY_INIT_PRIORITY

LLVM ld doesn't have --print-output-format:

% ld --print-output-format
ld: error: unknown argument '--print-output-format'

So it would be always defaulting to SORT. I'm not sure what to
recommend.

Regards, Roger.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] x86: avoid SORT_BY_INIT_PRIORITY with old GNU ld
  2022-03-07 15:05 ` Roger Pau Monné
@ 2022-03-07 15:29   ` Jan Beulich
  2022-03-07 15:52     ` Roger Pau Monné
  0 siblings, 1 reply; 7+ messages in thread
From: Jan Beulich @ 2022-03-07 15:29 UTC (permalink / raw)
  To: Roger Pau Monné; +Cc: xen-devel, Andrew Cooper, Wei Liu

On 07.03.2022 16:05, Roger Pau Monné wrote:
> On Mon, Mar 07, 2022 at 02:49:32PM +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 <jbeulich@suse.com>
>> ---
>> Obviously this doesn't take care of old LLVM ld yet, if any care is
>> needed there in the first place.
>>
>> --- a/xen/arch/x86/arch.mk
>> +++ b/xen/arch/x86/arch.mk
>> @@ -70,6 +70,11 @@ ifeq ($(CONFIG_UBSAN),y)
>>  $(call cc-option-add,CFLAGS_UBSAN,CC,-fno-sanitize=alignment)
>>  endif
>>  
>> +# While not much better than going by raw GNU ld version, utilize that the
>> +# feature we're after has appeared in the same release as the
>> +# --print-output-format command line option.
>> +AFLAGS-$(call ld-option,--print-output-format) += -DHAVE_LD_SORT_BY_INIT_PRIORITY
> 
> LLVM ld doesn't have --print-output-format:
> 
> % ld --print-output-format
> ld: error: unknown argument '--print-output-format'
> 
> So it would be always defaulting to SORT. I'm not sure what to
> recommend.

Do you know if all versions we support know of SORT_BY_INIT_PRIORITY?

Jan



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] x86: avoid SORT_BY_INIT_PRIORITY with old GNU ld
  2022-03-07 15:29   ` Jan Beulich
@ 2022-03-07 15:52     ` Roger Pau Monné
  2022-03-07 16:15       ` Jan Beulich
  0 siblings, 1 reply; 7+ messages in thread
From: Roger Pau Monné @ 2022-03-07 15:52 UTC (permalink / raw)
  To: Jan Beulich; +Cc: xen-devel, Andrew Cooper, Wei Liu

On Mon, Mar 07, 2022 at 04:29:22PM +0100, Jan Beulich wrote:
> On 07.03.2022 16:05, Roger Pau Monné wrote:
> > On Mon, Mar 07, 2022 at 02:49:32PM +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 <jbeulich@suse.com>
> >> ---
> >> Obviously this doesn't take care of old LLVM ld yet, if any care is
> >> needed there in the first place.
> >>
> >> --- a/xen/arch/x86/arch.mk
> >> +++ b/xen/arch/x86/arch.mk
> >> @@ -70,6 +70,11 @@ ifeq ($(CONFIG_UBSAN),y)
> >>  $(call cc-option-add,CFLAGS_UBSAN,CC,-fno-sanitize=alignment)
> >>  endif
> >>  
> >> +# While not much better than going by raw GNU ld version, utilize that the
> >> +# feature we're after has appeared in the same release as the
> >> +# --print-output-format command line option.
> >> +AFLAGS-$(call ld-option,--print-output-format) += -DHAVE_LD_SORT_BY_INIT_PRIORITY
> > 
> > LLVM ld doesn't have --print-output-format:
> > 
> > % ld --print-output-format
> > ld: error: unknown argument '--print-output-format'
> > 
> > So it would be always defaulting to SORT. I'm not sure what to
> > recommend.
> 
> Do you know if all versions we support know of SORT_BY_INIT_PRIORITY?

Hm, I don't think we can assume that we support LLVM LD in 3.5. I'm
not even sure if LLVM 3.5 had LLD in the first place.

The first version that we care about and that we test is LLVM LD 6,
anything below that version is of unknown state.

I've tested you change with SORT_BY_INIT_PRIORITY on it and it seems
to be fine. This was on FreeBSD 12.3 version of LLD, not sure how
many changes have been backported from newer versions there.

Thanks, Roger.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] x86: avoid SORT_BY_INIT_PRIORITY with old GNU ld
  2022-03-07 15:52     ` Roger Pau Monné
@ 2022-03-07 16:15       ` Jan Beulich
  2022-03-07 16:23         ` Roger Pau Monné
  0 siblings, 1 reply; 7+ messages in thread
From: Jan Beulich @ 2022-03-07 16:15 UTC (permalink / raw)
  To: Roger Pau Monné; +Cc: xen-devel, Andrew Cooper, Wei Liu

On 07.03.2022 16:52, Roger Pau Monné wrote:
> On Mon, Mar 07, 2022 at 04:29:22PM +0100, Jan Beulich wrote:
>> On 07.03.2022 16:05, Roger Pau Monné wrote:
>>> On Mon, Mar 07, 2022 at 02:49:32PM +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 <jbeulich@suse.com>
>>>> ---
>>>> Obviously this doesn't take care of old LLVM ld yet, if any care is
>>>> needed there in the first place.
>>>>
>>>> --- a/xen/arch/x86/arch.mk
>>>> +++ b/xen/arch/x86/arch.mk
>>>> @@ -70,6 +70,11 @@ ifeq ($(CONFIG_UBSAN),y)
>>>>  $(call cc-option-add,CFLAGS_UBSAN,CC,-fno-sanitize=alignment)
>>>>  endif
>>>>  
>>>> +# While not much better than going by raw GNU ld version, utilize that the
>>>> +# feature we're after has appeared in the same release as the
>>>> +# --print-output-format command line option.
>>>> +AFLAGS-$(call ld-option,--print-output-format) += -DHAVE_LD_SORT_BY_INIT_PRIORITY
>>>
>>> LLVM ld doesn't have --print-output-format:
>>>
>>> % ld --print-output-format
>>> ld: error: unknown argument '--print-output-format'
>>>
>>> So it would be always defaulting to SORT. I'm not sure what to
>>> recommend.
>>
>> Do you know if all versions we support know of SORT_BY_INIT_PRIORITY?
> 
> Hm, I don't think we can assume that we support LLVM LD in 3.5. I'm
> not even sure if LLVM 3.5 had LLD in the first place.
> 
> The first version that we care about and that we test is LLVM LD 6,
> anything below that version is of unknown state.
> 
> I've tested you change with SORT_BY_INIT_PRIORITY on it and it seems
> to be fine. This was on FreeBSD 12.3 version of LLD, not sure how
> many changes have been backported from newer versions there.

I'm inclined to suggest then that we unconditionally enable use of
this, in the hope that we'll never see a bug report. But of course
this then again gets me into the business of needing to determine
the which ld variant we're working with. Looks like I won't be able
to escape this anymore ...

Jan



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] x86: avoid SORT_BY_INIT_PRIORITY with old GNU ld
  2022-03-07 16:15       ` Jan Beulich
@ 2022-03-07 16:23         ` Roger Pau Monné
  2022-03-07 16:30           ` Jan Beulich
  0 siblings, 1 reply; 7+ messages in thread
From: Roger Pau Monné @ 2022-03-07 16:23 UTC (permalink / raw)
  To: Jan Beulich; +Cc: xen-devel, Andrew Cooper, Wei Liu

On Mon, Mar 07, 2022 at 05:15:57PM +0100, Jan Beulich wrote:
> On 07.03.2022 16:52, Roger Pau Monné wrote:
> > On Mon, Mar 07, 2022 at 04:29:22PM +0100, Jan Beulich wrote:
> >> On 07.03.2022 16:05, Roger Pau Monné wrote:
> >>> On Mon, Mar 07, 2022 at 02:49:32PM +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 <jbeulich@suse.com>
> >>>> ---
> >>>> Obviously this doesn't take care of old LLVM ld yet, if any care is
> >>>> needed there in the first place.
> >>>>
> >>>> --- a/xen/arch/x86/arch.mk
> >>>> +++ b/xen/arch/x86/arch.mk
> >>>> @@ -70,6 +70,11 @@ ifeq ($(CONFIG_UBSAN),y)
> >>>>  $(call cc-option-add,CFLAGS_UBSAN,CC,-fno-sanitize=alignment)
> >>>>  endif
> >>>>  
> >>>> +# While not much better than going by raw GNU ld version, utilize that the
> >>>> +# feature we're after has appeared in the same release as the
> >>>> +# --print-output-format command line option.
> >>>> +AFLAGS-$(call ld-option,--print-output-format) += -DHAVE_LD_SORT_BY_INIT_PRIORITY
> >>>
> >>> LLVM ld doesn't have --print-output-format:
> >>>
> >>> % ld --print-output-format
> >>> ld: error: unknown argument '--print-output-format'
> >>>
> >>> So it would be always defaulting to SORT. I'm not sure what to
> >>> recommend.
> >>
> >> Do you know if all versions we support know of SORT_BY_INIT_PRIORITY?
> > 
> > Hm, I don't think we can assume that we support LLVM LD in 3.5. I'm
> > not even sure if LLVM 3.5 had LLD in the first place.
> > 
> > The first version that we care about and that we test is LLVM LD 6,
> > anything below that version is of unknown state.
> > 
> > I've tested you change with SORT_BY_INIT_PRIORITY on it and it seems
> > to be fine. This was on FreeBSD 12.3 version of LLD, not sure how
> > many changes have been backported from newer versions there.
> 
> I'm inclined to suggest then that we unconditionally enable use of
> this, in the hope that we'll never see a bug report.

It's unlikely for anyone to try to use LLD < 6, as that wasn't
considered capable of linking the FreeBSD kernel. In fact I should
likely suggest an update to the README file for comments, as with my
FreeBSD hat I only care about LLVM >= 6.

> But of course
> this then again gets me into the business of needing to determine
> the which ld variant we're working with. Looks like I won't be able
> to escape this anymore ...

I assume bumping binutils minimum version to 2.22 is not a viable
option?

Thanks, Roger.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] x86: avoid SORT_BY_INIT_PRIORITY with old GNU ld
  2022-03-07 16:23         ` Roger Pau Monné
@ 2022-03-07 16:30           ` Jan Beulich
  0 siblings, 0 replies; 7+ messages in thread
From: Jan Beulich @ 2022-03-07 16:30 UTC (permalink / raw)
  To: Roger Pau Monné; +Cc: xen-devel, Andrew Cooper, Wei Liu

On 07.03.2022 17:23, Roger Pau Monné wrote:
> I assume bumping binutils minimum version to 2.22 is not a viable
> option?

It's an option, but is also part of the bigger area of determining
what the baseline tool chain requirements should be established from.

Jan



^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2022-03-07 16:30 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-07 13:49 [PATCH] x86: avoid SORT_BY_INIT_PRIORITY with old GNU ld Jan Beulich
2022-03-07 15:05 ` Roger Pau Monné
2022-03-07 15:29   ` Jan Beulich
2022-03-07 15:52     ` Roger Pau Monné
2022-03-07 16:15       ` Jan Beulich
2022-03-07 16:23         ` Roger Pau Monné
2022-03-07 16:30           ` Jan Beulich

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.