Loaders respecting IMAGE_SCN_MEM_DISCARDABLE would not load such sections,
yet we need to access it ourselves when switching out of "physical mode".
Leverage behavior new to GNU ld 2.46: Any contribution to .reloc which
doesn't have the discardable flag set (which cannot even be expressed in
ELF) will yield the output section also non-discardable.
Since for intermediate binaries we don't care about section attributes,
link in the new object only on the final linking pass.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
With a new enough linker, $(dot-target).2r.o could be leveraged instead:
$(dot-target).2r.S is going to be empty (or if it's not, the .reloc
section there would already have the wanted property), so instead of
adding the new relocs-empty.S we could also insert the section directive
there. Overall that seemed more convoluted to me, though.
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -196,7 +196,8 @@ note_file_option ?= $(note_file)
extra-$(XEN_BUILD_PE) += efi.lds
ifeq ($(XEN_BUILD_PE),y)
-$(TARGET).efi: $(objtree)/prelink.o $(note_file) $(obj)/efi.lds $(obj)/efi/relocs-dummy.o $(obj)/efi/mkreloc
+$(TARGET).efi: $(obj)/efi/relocs-dummy.o $(obj)/efi/relocs-empty.o $(obj)/efi/mkreloc
+$(TARGET).efi: $(objtree)/prelink.o $(note_file) $(obj)/efi.lds
ifeq ($(CONFIG_DEBUG_INFO),y)
$(if $(filter --strip-debug,$(EFI_LDFLAGS)),echo,:) "Will strip debug info from $(@F)"
endif
@@ -227,7 +228,7 @@ endif
$(MAKE) $(build)=$(@D) .$(@F).2r.o .$(@F).2s.o
$(call compare-symbol-tables, $(dot-target).1r.o, $(dot-target).2r.o)
$(call compare-symbol-tables, $(dot-target).1s.o, $(dot-target).2s.o)
- $(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T $(obj)/efi.lds $< \
+ $(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T $(obj)/efi.lds $< $(obj)/efi/relocs-empty.o \
$(dot-target).2r.o $(dot-target).2s.o $(orphan-handling-y) \
$(note_file_option) -o $@
$(NM) -pa --format=sysv $@ \
@@ -247,7 +248,7 @@ $(TARGET).efi: FORCE
endif
# These should already have been rebuilt when building the prerequisite of "prelink.o"
-$(obj)/efi/buildid.o $(obj)/efi/relocs-dummy.o: ;
+$(obj)/efi/buildid.o $(obj)/efi/relocs-dummy.o $(obj)/efi/relocs-empty.o: ;
.PHONY: include
include: $(objtree)/arch/x86/include/asm/asm-macros.h
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -17,5 +17,5 @@ obj-y := common-stub.o stub.o
obj-$(XEN_BUILD_EFI) := $(filter-out %.init.o,$(EFIOBJ-y))
obj-bin-$(XEN_BUILD_EFI) := $(filter %.init.o,$(EFIOBJ-y))
obj-bin-y += mbi2.init.o
-extra-$(XEN_BUILD_EFI) += buildid.o relocs-dummy.o
+extra-$(XEN_BUILD_EFI) += buildid.o relocs-dummy.o relocs-empty.o
nocov-$(XEN_BUILD_EFI) += stub.o
--- /dev/null
+++ b/xen/arch/x86/efi/relocs-empty.S
@@ -0,0 +1,8 @@
+/*
+ * Empty .reloc section, simply to indicate to GNU ld that the output .reloc
+ * section in xen.efi should not be marked IMAGE_SCN_MEM_DISCARDABLE. This
+ * requires GNU ld 2.46 or newer to actually be understood in the intended way.
+ */
+
+ .section .reloc, "a", @progbits
+ .balign 4On Tue, Jun 16, 2026 at 06:17:54PM +0200, Jan Beulich wrote: > Loaders respecting IMAGE_SCN_MEM_DISCARDABLE would not load such sections, > yet we need to access it ourselves when switching out of "physical mode". > Leverage behavior new to GNU ld 2.46: Any contribution to .reloc which > doesn't have the discardable flag set (which cannot even be expressed in > ELF) will yield the output section also non-discardable. > > Since for intermediate binaries we don't care about section attributes, > link in the new object only on the final linking pass. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> This seems to be enough to indeed make xen.efi .reloc non-discardable with binutils 2.46. Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> > --- > With a new enough linker, $(dot-target).2r.o could be leveraged instead: > $(dot-target).2r.S is going to be empty (or if it's not, the .reloc > section there would already have the wanted property), so instead of > adding the new relocs-empty.S we could also insert the section directive > there. Overall that seemed more convoluted to me, though. > > --- a/xen/arch/x86/Makefile > +++ b/xen/arch/x86/Makefile > @@ -196,7 +196,8 @@ note_file_option ?= $(note_file) > > extra-$(XEN_BUILD_PE) += efi.lds > ifeq ($(XEN_BUILD_PE),y) > -$(TARGET).efi: $(objtree)/prelink.o $(note_file) $(obj)/efi.lds $(obj)/efi/relocs-dummy.o $(obj)/efi/mkreloc > +$(TARGET).efi: $(obj)/efi/relocs-dummy.o $(obj)/efi/relocs-empty.o $(obj)/efi/mkreloc > +$(TARGET).efi: $(objtree)/prelink.o $(note_file) $(obj)/efi.lds > ifeq ($(CONFIG_DEBUG_INFO),y) > $(if $(filter --strip-debug,$(EFI_LDFLAGS)),echo,:) "Will strip debug info from $(@F)" > endif > @@ -227,7 +228,7 @@ endif > $(MAKE) $(build)=$(@D) .$(@F).2r.o .$(@F).2s.o > $(call compare-symbol-tables, $(dot-target).1r.o, $(dot-target).2r.o) > $(call compare-symbol-tables, $(dot-target).1s.o, $(dot-target).2s.o) > - $(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T $(obj)/efi.lds $< \ > + $(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T $(obj)/efi.lds $< $(obj)/efi/relocs-empty.o \ > $(dot-target).2r.o $(dot-target).2s.o $(orphan-handling-y) \ > $(note_file_option) -o $@ > $(NM) -pa --format=sysv $@ \ > @@ -247,7 +248,7 @@ $(TARGET).efi: FORCE > endif > > # These should already have been rebuilt when building the prerequisite of "prelink.o" > -$(obj)/efi/buildid.o $(obj)/efi/relocs-dummy.o: ; > +$(obj)/efi/buildid.o $(obj)/efi/relocs-dummy.o $(obj)/efi/relocs-empty.o: ; > > .PHONY: include > include: $(objtree)/arch/x86/include/asm/asm-macros.h > --- a/xen/arch/x86/efi/Makefile > +++ b/xen/arch/x86/efi/Makefile > @@ -17,5 +17,5 @@ obj-y := common-stub.o stub.o > obj-$(XEN_BUILD_EFI) := $(filter-out %.init.o,$(EFIOBJ-y)) > obj-bin-$(XEN_BUILD_EFI) := $(filter %.init.o,$(EFIOBJ-y)) > obj-bin-y += mbi2.init.o > -extra-$(XEN_BUILD_EFI) += buildid.o relocs-dummy.o > +extra-$(XEN_BUILD_EFI) += buildid.o relocs-dummy.o relocs-empty.o > nocov-$(XEN_BUILD_EFI) += stub.o > --- /dev/null > +++ b/xen/arch/x86/efi/relocs-empty.S > @@ -0,0 +1,8 @@ > +/* > + * Empty .reloc section, simply to indicate to GNU ld that the output .reloc > + * section in xen.efi should not be marked IMAGE_SCN_MEM_DISCARDABLE. This > + * requires GNU ld 2.46 or newer to actually be understood in the intended way. > + */ > + > + .section .reloc, "a", @progbits > + .balign 4 -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab
On 6/16/26 18:20, Jan Beulich wrote: > Loaders respecting IMAGE_SCN_MEM_DISCARDABLE would not load such sections, > yet we need to access it ourselves when switching out of "physical mode". > Leverage behavior new to GNU ld 2.46: Any contribution to .reloc which > doesn't have the discardable flag set (which cannot even be expressed in > ELF) will yield the output section also non-discardable. > > Since for intermediate binaries we don't care about section attributes, > link in the new object only on the final linking pass. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> Can I get a Reported-by tag on this one? Since I reported the issue with a patch a few months ago: https://lore.kernel.org/xen-devel/20250724140731.1502774-1-yann.sionneau@vates.tech/ Thanks and congratz for the binutils fixes integration! Regards, -- -- | Vates XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech
On 23.06.2026 10:02, Yann Sionneau wrote: > On 6/16/26 18:20, Jan Beulich wrote: >> Loaders respecting IMAGE_SCN_MEM_DISCARDABLE would not load such sections, >> yet we need to access it ourselves when switching out of "physical mode". >> Leverage behavior new to GNU ld 2.46: Any contribution to .reloc which >> doesn't have the discardable flag set (which cannot even be expressed in >> ELF) will yield the output section also non-discardable. >> >> Since for intermediate binaries we don't care about section attributes, >> link in the new object only on the final linking pass. >> >> Signed-off-by: Jan Beulich <jbeulich@suse.com> > Can I get a Reported-by tag on this one? > Since I reported the issue with a patch a few months ago: > https://lore.kernel.org/xen-devel/20250724140731.1502774-1-yann.sionneau@vates.tech/ Hmm, I have to admit I'm of split minds here. Generally I'd expect Reported-by: to only cover new findings (or if two people observed the same thing independently within a short time frame). The (abstract) problem with the section attributes of .reloc was known long ago. The aspect speaking in favor of adding the tag is that you apparently were the first one to report encountering the issue in practice. Jan
On 6/16/26 6:17 PM, Jan Beulich wrote: > Loaders respecting IMAGE_SCN_MEM_DISCARDABLE would not load such sections, > yet we need to access it ourselves when switching out of "physical mode". > Leverage behavior new to GNU ld 2.46: Any contribution to .reloc which > doesn't have the discardable flag set (which cannot even be expressed in > ELF) will yield the output section also non-discardable. > > Since for intermediate binaries we don't care about section attributes, > link in the new object only on the final linking pass. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> Thanks. ~ Oleksii
On 17.06.2026 12:56, Oleksii Kurochko wrote: > On 6/16/26 6:17 PM, Jan Beulich wrote: >> Loaders respecting IMAGE_SCN_MEM_DISCARDABLE would not load such sections, >> yet we need to access it ourselves when switching out of "physical mode". >> Leverage behavior new to GNU ld 2.46: Any contribution to .reloc which >> doesn't have the discardable flag set (which cannot even be expressed in >> ELF) will yield the output section also non-discardable. >> >> Since for intermediate binaries we don't care about section attributes, >> link in the new object only on the final linking pass. >> >> Signed-off-by: Jan Beulich <jbeulich@suse.com> > > Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> May I please ask for an "ordinary" ack here as well, so this change can go in? Note that Roger's ack covers, as to its formal meaning, most of the change, but not the new file introduced. Thanks, Jan
On Tue, Jun 16, 2026 at 06:17:54PM +0200, Jan Beulich wrote: > Loaders respecting IMAGE_SCN_MEM_DISCARDABLE would not load such sections, > yet we need to access it ourselves when switching out of "physical mode". > Leverage behavior new to GNU ld 2.46: Any contribution to .reloc which > doesn't have the discardable flag set (which cannot even be expressed in > ELF) will yield the output section also non-discardable. > > Since for intermediate binaries we don't care about section attributes, > link in the new object only on the final linking pass. I'm not sure I follow. Xen already does generate a custom .reloc section without the IMAGE_SCN_MEM_DISCARDABLE attribute when using the mkreloc utility, and hence the .reloc section should never be marked as discardable? Thanks, Roger.
On 17.06.2026 12:29, Roger Pau Monné wrote: > On Tue, Jun 16, 2026 at 06:17:54PM +0200, Jan Beulich wrote: >> Loaders respecting IMAGE_SCN_MEM_DISCARDABLE would not load such sections, >> yet we need to access it ourselves when switching out of "physical mode". >> Leverage behavior new to GNU ld 2.46: Any contribution to .reloc which >> doesn't have the discardable flag set (which cannot even be expressed in >> ELF) will yield the output section also non-discardable. >> >> Since for intermediate binaries we don't care about section attributes, >> link in the new object only on the final linking pass. > > I'm not sure I follow. Xen already does generate a custom .reloc > section without the IMAGE_SCN_MEM_DISCARDABLE attribute when using > the mkreloc utility, and hence the .reloc section should never be > marked as discardable? mkreloc is used only when we recognize the linker to be incapable of producing (correct) base relocations. As a modern linker is required for the desired IMAGE_SCN_MEM_DISCARDABLE handling for .reloc, mkreloc wouldn't normally be used there. Hence no .reloc section with the wanted property. Jan
On 17/06/2026 11:37 am, Jan Beulich wrote: > On 17.06.2026 12:29, Roger Pau Monné wrote: >> On Tue, Jun 16, 2026 at 06:17:54PM +0200, Jan Beulich wrote: >>> Loaders respecting IMAGE_SCN_MEM_DISCARDABLE would not load such sections, >>> yet we need to access it ourselves when switching out of "physical mode". >>> Leverage behavior new to GNU ld 2.46: Any contribution to .reloc which >>> doesn't have the discardable flag set (which cannot even be expressed in >>> ELF) will yield the output section also non-discardable. >>> >>> Since for intermediate binaries we don't care about section attributes, >>> link in the new object only on the final linking pass. >> I'm not sure I follow. Xen already does generate a custom .reloc >> section without the IMAGE_SCN_MEM_DISCARDABLE attribute when using >> the mkreloc utility, and hence the .reloc section should never be >> marked as discardable? > mkreloc is used only when we recognize the linker to be incapable of > producing (correct) base relocations. I wasn't even aware of that behaviour. So we've got even more completely undocumented and obscure toolchain restrictions and behaviours. What else? It needs at least enumerating somewhere so people stand a chance of being able figure out which toolstack they need in order to get a functioning xen.efi. I'm going to insist that a doc happens, and that this patch patches it adding in the Binutils 2.46 requirement. But I'll write the doc if you can summarise the other checks I'm not aware of. ~Andrew
On 17.06.2026 13:20, Andrew Cooper wrote: > On 17/06/2026 11:37 am, Jan Beulich wrote: >> On 17.06.2026 12:29, Roger Pau Monné wrote: >>> On Tue, Jun 16, 2026 at 06:17:54PM +0200, Jan Beulich wrote: >>>> Loaders respecting IMAGE_SCN_MEM_DISCARDABLE would not load such sections, >>>> yet we need to access it ourselves when switching out of "physical mode". >>>> Leverage behavior new to GNU ld 2.46: Any contribution to .reloc which >>>> doesn't have the discardable flag set (which cannot even be expressed in >>>> ELF) will yield the output section also non-discardable. >>>> >>>> Since for intermediate binaries we don't care about section attributes, >>>> link in the new object only on the final linking pass. >>> I'm not sure I follow. Xen already does generate a custom .reloc >>> section without the IMAGE_SCN_MEM_DISCARDABLE attribute when using >>> the mkreloc utility, and hence the .reloc section should never be >>> marked as discardable? >> mkreloc is used only when we recognize the linker to be incapable of >> producing (correct) base relocations. > > I wasn't even aware of that behaviour. > > So we've got even more completely undocumented and obscure toolchain > restrictions and behaviours. > > What else? It needs at least enumerating somewhere so people stand a > chance of being able figure out which toolstack they need in order to > get a functioning xen.efi. The two ways of generating relocations exist to allow people to build a functioning xen.efi irrespective of GNU ld version used. Hence it's not quite clear to me ... > I'm going to insist that a doc happens, and that this patch patches it > adding in the Binutils 2.46 requirement. > > But I'll write the doc if you can summarise the other checks I'm not > aware of. ... what exactly you want to document. The change here is towards secure boot support; outside of that xen.efi is operating okay in this regard, afaik. The first paragraph of docs/misc/efi.pandoc could do with an update (as the version restrictions are now obsolete), but it was my understanding that the secure boot related aspects all would live in a new, to be created doc (which iirc you already have in flight). Besides the .reloc filling, the other check we have is for whether to include debug info. As with the documentation on toolchain versions required, the MS ABI check could likely be dropped now as well. Otoh the "linker supports PE" check of course needs to remain. Jan
On Wed, Jun 17, 2026 at 12:37:38PM +0200, Jan Beulich wrote: > On 17.06.2026 12:29, Roger Pau Monné wrote: > > On Tue, Jun 16, 2026 at 06:17:54PM +0200, Jan Beulich wrote: > >> Loaders respecting IMAGE_SCN_MEM_DISCARDABLE would not load such sections, > >> yet we need to access it ourselves when switching out of "physical mode". > >> Leverage behavior new to GNU ld 2.46: Any contribution to .reloc which > >> doesn't have the discardable flag set (which cannot even be expressed in > >> ELF) will yield the output section also non-discardable. > >> > >> Since for intermediate binaries we don't care about section attributes, > >> link in the new object only on the final linking pass. > > > > I'm not sure I follow. Xen already does generate a custom .reloc > > section without the IMAGE_SCN_MEM_DISCARDABLE attribute when using > > the mkreloc utility, and hence the .reloc section should never be > > marked as discardable? > > mkreloc is used only when we recognize the linker to be incapable of > producing (correct) base relocations. As a modern linker is required for > the desired IMAGE_SCN_MEM_DISCARDABLE handling for .reloc, mkreloc > wouldn't normally be used there. Hence no .reloc section with the wanted > property. I see, MKRELOC becomes ":" then, I didn't catch that. Acked-by: Roger Pau Monné <roger.pau@citrix.com> Thanks, Roger.
© 2016 - 2026 Red Hat, Inc.