[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH] x86: avoid SORT_BY_INIT_PRIORITY with old GNU ld
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@xxxxxxxx> >>>> --- >>>> 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |