diff mbox series

x86: avoid SORT_BY_INIT_PRIORITY with old GNU ld

Message ID 8b982bab-9b16-61e7-620f-5a5b2be39588@suse.com (mailing list archive)
State Superseded
Headers show
Series x86: avoid SORT_BY_INIT_PRIORITY with old GNU ld | expand

Commit Message

Jan Beulich March 7, 2022, 1:49 p.m. UTC
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.

Comments

Roger Pau Monné March 7, 2022, 3:05 p.m. UTC | #1
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.
Jan Beulich March 7, 2022, 3:29 p.m. UTC | #2
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
Roger Pau Monné March 7, 2022, 3:52 p.m. UTC | #3
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.
Jan Beulich March 7, 2022, 4:15 p.m. UTC | #4
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
Roger Pau Monné March 7, 2022, 4:23 p.m. UTC | #5
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.
Jan Beulich March 7, 2022, 4:30 p.m. UTC | #6
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
diff mbox series

Patch

--- 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)