[PATCH v8] xen: Strip xen.efi by default

Frediano Ziglio posted 1 patch 2 months, 3 weeks ago
Patches applied successfully (tree, apply log)
git fetch https://gitlab.com/xen-project/patchew/xen tags/patchew/20251113154358.28704-1-frediano.ziglio@citrix.com
There is a newer version of this series
.gitignore            |  1 +
CHANGELOG.md          |  3 +++
docs/misc/efi.pandoc  |  8 +-------
xen/Kconfig.debug     |  9 ++-------
xen/Makefile          | 25 +++----------------------
xen/arch/x86/Makefile | 11 ++++++++---
6 files changed, 18 insertions(+), 39 deletions(-)
[PATCH v8] xen: Strip xen.efi by default
Posted by Frediano Ziglio 2 months, 3 weeks ago
From: Frediano Ziglio <frediano.ziglio@cloud.com>

For xen.gz file we strip all symbols and have an additional
xen-syms.efi file version with all symbols.
Make xen.efi more coherent stripping all symbols too.
xen-syms.efi can be used for debugging.

Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
---
Changes since v1:
- avoid leaving target if some command fails.

Changes since v2:
- do not convert type but retain PE format;
- use xen-syms.efi for new file name, more consistent with ELF.

Changes since v3:
- update documentation;
- do not remove xen.efi.elf;
- check endbr instruction before generating final target.

Changes since v4:
- simplify condition check;
- avoid reuse of $@.tmp file.

Changes since v5:
- avoid creation of temporary file.

Changes since v6:
- install xen-syms.efi;
- always strip xen.efi;
- restore EFI_LDFLAGS check during rule execution;
- update CHANGELOG.md;
- added xen-syms.efi to .gitignore.

Changes since v7:
- move and improve CHANGELOG.md changes.
---
 .gitignore            |  1 +
 CHANGELOG.md          |  3 +++
 docs/misc/efi.pandoc  |  8 +-------
 xen/Kconfig.debug     |  9 ++-------
 xen/Makefile          | 25 +++----------------------
 xen/arch/x86/Makefile | 11 ++++++++---
 6 files changed, 18 insertions(+), 39 deletions(-)

diff --git a/.gitignore b/.gitignore
index d83427aba8..213972b65c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -222,6 +222,7 @@ tools/flask/policy/xenpolicy-*
 xen/xen
 xen/suppression-list.txt
 xen/xen-syms
+xen/xen-syms.efi
 xen/xen-syms.map
 xen/xen.*
 
diff --git a/CHANGELOG.md b/CHANGELOG.md
index c9932a2af0..bc16e316e7 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -34,6 +34,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
      BAR for HVM guests, to improve performance of guests using it to map the
      grant table or foreign memory.
    - Allow configuring the number of altp2m tables per domain via vm.cfg.
+   - The install-time environment variable INSTALL_EFI_STRIP no longer exists.
+     xen.efi is always stripped, while the symbols remain available in
+     xen-syms.efi.
 
 ### Added
  - Introduce new PDX compression algorithm to cope with Intel Sierra Forest and
diff --git a/docs/misc/efi.pandoc b/docs/misc/efi.pandoc
index 11c1ac3346..c66b18a66b 100644
--- a/docs/misc/efi.pandoc
+++ b/docs/misc/efi.pandoc
@@ -20,13 +20,7 @@ Xen to load the configuration file even if multiboot modules are found.
 Once built, `make install-xen` will place the resulting binary directly into
 the EFI boot partition, provided `EFI_VENDOR` is set in the environment (and
 `EFI_MOUNTPOINT` is overridden as needed, should the default of `/boot/efi` not
-match your system). When built with debug info, the binary can be quite large.
-Setting `INSTALL_EFI_STRIP=1` in the environment will cause it to be stripped
-of debug info in the process of installing. `INSTALL_EFI_STRIP` can also be set
-to any combination of options suitable to pass to `strip`, in case the default
-ones don't do. The xen.efi binary will also be installed in `/usr/lib64/efi/`,
-unless `EFI_DIR` is set in the environment to override this default. This
-binary will not be stripped in the process.
+match your system).
 
 The binary itself will require a configuration file (names with the `.efi`
 extension of the binary's name replaced by `.cfg`, and - until an existing
diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index d900d926c5..1a8e0c6ec3 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -147,12 +147,7 @@ config DEBUG_INFO
 	  Say Y here if you want to build Xen with debug information. This
 	  information is needed e.g. for doing crash dump analysis of the
 	  hypervisor via the "crash" tool.
-	  Saying Y will increase the size of the xen-syms and xen.efi
-	  binaries. In case the space on the EFI boot partition is rather
-	  limited, you may want to install a stripped variant of xen.efi in
-	  the EFI boot partition (look for "INSTALL_EFI_STRIP" in
-	  docs/misc/efi.pandoc for more information - when not using
-	  "make install-xen" for installing xen.efi, stripping needs to be
-	  done outside the Xen build environment).
+	  Saying Y will increase the size of the xen-syms, xen-syms.efi and
+	  xen.efi.elf binaries.
 
 endmenu
diff --git a/xen/Makefile b/xen/Makefile
index fc9244420e..5ed029fed1 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -493,22 +493,6 @@ endif
 .PHONY: _build
 _build: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
 
-# Strip
-#
-# INSTALL_EFI_STRIP, if defined, will cause xen.efi to be stripped before it
-# is installed. If INSTALL_EFI_STRIP is '1', then the default option(s) below
-# will be used. Otherwise, INSTALL_EFI_STRIP value will be used as the
-# option(s) to the strip command.
-ifdef INSTALL_EFI_STRIP
-
-ifeq ($(INSTALL_EFI_STRIP),1)
-efi-strip-opt := --strip-debug --keep-file-symbols
-else
-efi-strip-opt := $(INSTALL_EFI_STRIP)
-endif
-
-endif
-
 .PHONY: _install
 _install: D=$(DESTDIR)
 _install: T=$(notdir $(TARGET))
@@ -526,18 +510,15 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
 	if [ -r $(TARGET).efi -a -n '$(EFI_DIR)' ]; then \
 		[ -d $(D)$(EFI_DIR) ] || $(INSTALL_DIR) $(D)$(EFI_DIR); \
 		$(INSTALL_DATA) $(TARGET).efi $(D)$(EFI_DIR)/$(T)-$(XEN_FULLVERSION).efi; \
-		for x in map elf; do \
-			if [ -e $(TARGET).efi.$$x ]; then \
-				$(INSTALL_DATA) $(TARGET).efi.$$x $(D)$(DEBUG_DIR)/$(T)-$(XEN_FULLVERSION).efi.$$x; \
+		for x in .efi.map .efi.elf -syms.efi; do \
+			if [ -e $(TARGET)$$x ]; then \
+				$(INSTALL_DATA) $(TARGET)$$x $(D)$(DEBUG_DIR)/$(T)-$(XEN_FULLVERSION)$$x; \
 			fi; \
 		done; \
 		ln -sf $(T)-$(XEN_FULLVERSION).efi $(D)$(EFI_DIR)/$(T)-$(XEN_VERSION).$(XEN_SUBVERSION).efi; \
 		ln -sf $(T)-$(XEN_FULLVERSION).efi $(D)$(EFI_DIR)/$(T)-$(XEN_VERSION).efi; \
 		ln -sf $(T)-$(XEN_FULLVERSION).efi $(D)$(EFI_DIR)/$(T).efi; \
 		if [ -n '$(EFI_MOUNTPOINT)' -a -n '$(EFI_VENDOR)' ]; then \
-			$(if $(efi-strip-opt), \
-			     $(STRIP) $(efi-strip-opt) -p -o $(TARGET).efi.stripped $(TARGET).efi && \
-			     $(INSTALL_DATA) $(TARGET).efi.stripped $(D)$(EFI_MOUNTPOINT)/efi/$(EFI_VENDOR)/$(T)-$(XEN_FULLVERSION).efi ||) \
 			$(INSTALL_DATA) $(TARGET).efi $(D)$(EFI_MOUNTPOINT)/efi/$(EFI_VENDOR)/$(T)-$(XEN_FULLVERSION).efi; \
 		elif [ "$(D)" = "$(patsubst $(shell cd $(XEN_ROOT) && pwd)/%,%,$(D))" ]; then \
 			echo 'EFI installation only partially done (EFI_VENDOR not set)' >&2; \
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 407571c510..a154ffe6b2 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -228,12 +228,17 @@ endif
 	$(MAKE) $(build)=$(@D) .$(@F).1r.o .$(@F).1s.o
 	$(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T $(obj)/efi.lds $< \
 	      $(dot-target).1r.o $(dot-target).1s.o $(orphan-handling-y) \
-	      $(note_file_option) -o $@
-	$(NM) -pa --format=sysv $@ \
+	      $(note_file_option) -o $(TARGET)-syms.efi
+	$(NM) -pa --format=sysv $(TARGET)-syms.efi \
 		| $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \
 		> $@.map
 ifeq ($(CONFIG_DEBUG_INFO),y)
-	$(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) -O elf64-x86-64 $@ $@.elf
+	$(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) \
+		-O elf64-x86-64 $(TARGET)-syms.efi $@.elf
+endif
+	$(STRIP) $(TARGET)-syms.efi -o $@
+ifneq ($(CONFIG_DEBUG_INFO),y)
+	rm -f $(TARGET)-syms.efi
 endif
 	rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]*
 ifeq ($(CONFIG_XEN_IBT),y)
-- 
2.43.0
Re: [PATCH v8] xen: Strip xen.efi by default
Posted by Oleksii Kurochko 2 months, 3 weeks ago
On 11/13/25 4:43 PM, Frediano Ziglio wrote:
> From: Frediano Ziglio<frediano.ziglio@cloud.com>
>
> For xen.gz file we strip all symbols and have an additional
> xen-syms.efi file version with all symbols.
> Make xen.efi more coherent stripping all symbols too.
> xen-syms.efi can be used for debugging.
>
> Signed-off-by: Frediano Ziglio<frediano.ziglio@cloud.com>

Release-Acked-By: Oleksii Kurochko<oleksii.kurochko@gmail.com>

Thanks.

~ Oleksii

> ---
> Changes since v1:
> - avoid leaving target if some command fails.
>
> Changes since v2:
> - do not convert type but retain PE format;
> - use xen-syms.efi for new file name, more consistent with ELF.
>
> Changes since v3:
> - update documentation;
> - do not remove xen.efi.elf;
> - check endbr instruction before generating final target.
>
> Changes since v4:
> - simplify condition check;
> - avoid reuse of $@.tmp file.
>
> Changes since v5:
> - avoid creation of temporary file.
>
> Changes since v6:
> - install xen-syms.efi;
> - always strip xen.efi;
> - restore EFI_LDFLAGS check during rule execution;
> - update CHANGELOG.md;
> - added xen-syms.efi to .gitignore.
>
> Changes since v7:
> - move and improve CHANGELOG.md changes.
> ---
>   .gitignore            |  1 +
>   CHANGELOG.md          |  3 +++
>   docs/misc/efi.pandoc  |  8 +-------
>   xen/Kconfig.debug     |  9 ++-------
>   xen/Makefile          | 25 +++----------------------
>   xen/arch/x86/Makefile | 11 ++++++++---
>   6 files changed, 18 insertions(+), 39 deletions(-)
>
> diff --git a/.gitignore b/.gitignore
> index d83427aba8..213972b65c 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -222,6 +222,7 @@ tools/flask/policy/xenpolicy-*
>   xen/xen
>   xen/suppression-list.txt
>   xen/xen-syms
> +xen/xen-syms.efi
>   xen/xen-syms.map
>   xen/xen.*
>   
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> index c9932a2af0..bc16e316e7 100644
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -34,6 +34,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>        BAR for HVM guests, to improve performance of guests using it to map the
>        grant table or foreign memory.
>      - Allow configuring the number of altp2m tables per domain via vm.cfg.
> +   - The install-time environment variable INSTALL_EFI_STRIP no longer exists.
> +     xen.efi is always stripped, while the symbols remain available in
> +     xen-syms.efi.
>   
>   ### Added
>    - Introduce new PDX compression algorithm to cope with Intel Sierra Forest and
> diff --git a/docs/misc/efi.pandoc b/docs/misc/efi.pandoc
> index 11c1ac3346..c66b18a66b 100644
> --- a/docs/misc/efi.pandoc
> +++ b/docs/misc/efi.pandoc
> @@ -20,13 +20,7 @@ Xen to load the configuration file even if multiboot modules are found.
>   Once built, `make install-xen` will place the resulting binary directly into
>   the EFI boot partition, provided `EFI_VENDOR` is set in the environment (and
>   `EFI_MOUNTPOINT` is overridden as needed, should the default of `/boot/efi` not
> -match your system). When built with debug info, the binary can be quite large.
> -Setting `INSTALL_EFI_STRIP=1` in the environment will cause it to be stripped
> -of debug info in the process of installing. `INSTALL_EFI_STRIP` can also be set
> -to any combination of options suitable to pass to `strip`, in case the default
> -ones don't do. The xen.efi binary will also be installed in `/usr/lib64/efi/`,
> -unless `EFI_DIR` is set in the environment to override this default. This
> -binary will not be stripped in the process.
> +match your system).
>   
>   The binary itself will require a configuration file (names with the `.efi`
>   extension of the binary's name replaced by `.cfg`, and - until an existing
> diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
> index d900d926c5..1a8e0c6ec3 100644
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -147,12 +147,7 @@ config DEBUG_INFO
>   	  Say Y here if you want to build Xen with debug information. This
>   	  information is needed e.g. for doing crash dump analysis of the
>   	  hypervisor via the "crash" tool.
> -	  Saying Y will increase the size of the xen-syms and xen.efi
> -	  binaries. In case the space on the EFI boot partition is rather
> -	  limited, you may want to install a stripped variant of xen.efi in
> -	  the EFI boot partition (look for "INSTALL_EFI_STRIP" in
> -	  docs/misc/efi.pandoc for more information - when not using
> -	  "make install-xen" for installing xen.efi, stripping needs to be
> -	  done outside the Xen build environment).
> +	  Saying Y will increase the size of the xen-syms, xen-syms.efi and
> +	  xen.efi.elf binaries.
>   
>   endmenu
> diff --git a/xen/Makefile b/xen/Makefile
> index fc9244420e..5ed029fed1 100644
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -493,22 +493,6 @@ endif
>   .PHONY: _build
>   _build: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
>   
> -# Strip
> -#
> -# INSTALL_EFI_STRIP, if defined, will cause xen.efi to be stripped before it
> -# is installed. If INSTALL_EFI_STRIP is '1', then the default option(s) below
> -# will be used. Otherwise, INSTALL_EFI_STRIP value will be used as the
> -# option(s) to the strip command.
> -ifdef INSTALL_EFI_STRIP
> -
> -ifeq ($(INSTALL_EFI_STRIP),1)
> -efi-strip-opt := --strip-debug --keep-file-symbols
> -else
> -efi-strip-opt := $(INSTALL_EFI_STRIP)
> -endif
> -
> -endif
> -
>   .PHONY: _install
>   _install: D=$(DESTDIR)
>   _install: T=$(notdir $(TARGET))
> @@ -526,18 +510,15 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
>   	if [ -r $(TARGET).efi -a -n '$(EFI_DIR)' ]; then \
>   		[ -d $(D)$(EFI_DIR) ] || $(INSTALL_DIR) $(D)$(EFI_DIR); \
>   		$(INSTALL_DATA) $(TARGET).efi $(D)$(EFI_DIR)/$(T)-$(XEN_FULLVERSION).efi; \
> -		for x in map elf; do \
> -			if [ -e $(TARGET).efi.$$x ]; then \
> -				$(INSTALL_DATA) $(TARGET).efi.$$x $(D)$(DEBUG_DIR)/$(T)-$(XEN_FULLVERSION).efi.$$x; \
> +		for x in .efi.map .efi.elf -syms.efi; do \
> +			if [ -e $(TARGET)$$x ]; then \
> +				$(INSTALL_DATA) $(TARGET)$$x $(D)$(DEBUG_DIR)/$(T)-$(XEN_FULLVERSION)$$x; \
>   			fi; \
>   		done; \
>   		ln -sf $(T)-$(XEN_FULLVERSION).efi $(D)$(EFI_DIR)/$(T)-$(XEN_VERSION).$(XEN_SUBVERSION).efi; \
>   		ln -sf $(T)-$(XEN_FULLVERSION).efi $(D)$(EFI_DIR)/$(T)-$(XEN_VERSION).efi; \
>   		ln -sf $(T)-$(XEN_FULLVERSION).efi $(D)$(EFI_DIR)/$(T).efi; \
>   		if [ -n '$(EFI_MOUNTPOINT)' -a -n '$(EFI_VENDOR)' ]; then \
> -			$(if $(efi-strip-opt), \
> -			     $(STRIP) $(efi-strip-opt) -p -o $(TARGET).efi.stripped $(TARGET).efi && \
> -			     $(INSTALL_DATA) $(TARGET).efi.stripped $(D)$(EFI_MOUNTPOINT)/efi/$(EFI_VENDOR)/$(T)-$(XEN_FULLVERSION).efi ||) \
>   			$(INSTALL_DATA) $(TARGET).efi $(D)$(EFI_MOUNTPOINT)/efi/$(EFI_VENDOR)/$(T)-$(XEN_FULLVERSION).efi; \
>   		elif [ "$(D)" = "$(patsubst $(shell cd $(XEN_ROOT) && pwd)/%,%,$(D))" ]; then \
>   			echo 'EFI installation only partially done (EFI_VENDOR not set)' >&2; \
> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> index 407571c510..a154ffe6b2 100644
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -228,12 +228,17 @@ endif
>   	$(MAKE) $(build)=$(@D) .$(@F).1r.o .$(@F).1s.o
>   	$(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T $(obj)/efi.lds $< \
>   	      $(dot-target).1r.o $(dot-target).1s.o $(orphan-handling-y) \
> -	      $(note_file_option) -o $@
> -	$(NM) -pa --format=sysv $@ \
> +	      $(note_file_option) -o $(TARGET)-syms.efi
> +	$(NM) -pa --format=sysv $(TARGET)-syms.efi \
>   		| $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \
>   		> $@.map
>   ifeq ($(CONFIG_DEBUG_INFO),y)
> -	$(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) -O elf64-x86-64 $@ $@.elf
> +	$(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) \
> +		-O elf64-x86-64 $(TARGET)-syms.efi $@.elf
> +endif
> +	$(STRIP) $(TARGET)-syms.efi -o $@
> +ifneq ($(CONFIG_DEBUG_INFO),y)
> +	rm -f $(TARGET)-syms.efi
>   endif
>   	rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]*
>   ifeq ($(CONFIG_XEN_IBT),y)
Re: [PATCH v8] xen: Strip xen.efi by default
Posted by Andrew Cooper 2 months, 3 weeks ago
On 14/11/2025 3:40 pm, Oleksii Kurochko wrote:
>
>
> On 11/13/25 4:43 PM, Frediano Ziglio wrote:
>> From: Frediano Ziglio <frediano.ziglio@cloud.com>
>>
>> For xen.gz file we strip all symbols and have an additional
>> xen-syms.efi file version with all symbols.
>> Make xen.efi more coherent stripping all symbols too.
>> xen-syms.efi can be used for debugging.
>>
>> Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
> Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
>
> Thanks.

Thanks.  Unfortunately CI says no.

Ubuntu's 20.04, 18.04 and 16.04 all fail: 
https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2159622869

From 16.04:

2025-11-14T18:01:51.192964Z 01O strip xen-syms.efi -o xen.efi
2025-11-14T18:01:51.198151Z 01O strip:xen-syms.efi[.init]: relocation count is negative: File truncated
2025-11-14T18:01:51.198166Z 01O strip: xen.efi: Failed to read debug data section
2025-11-14T18:01:51.198169Z 01O strip:xen.efi: error copying private BFD data: File truncated
2025-11-14T18:01:51.198932Z 01O arch/x86/Makefile:207: recipe for target 'xen.efi' failed
2025-11-14T18:01:51.198937Z 01O make[3]: *** [xen.efi] Error 1
2025-11-14T18:01:51.199616Z 01O build.mk:90: recipe for target 'xen' failed
2025-11-14T18:01:51.199619Z 01O make[2]: *** [xen] Error 2
2025-11-14T18:01:51.200402Z 01O Makefile:600: recipe for target 'xen' failed
2025-11-14T18:01:51.200409Z 01O make[1]: *** [xen] Error 2


I find it hard to believe that the relocation count is really negative,
and given that newer binuitls works, I expect this is a binutils bug.

Nevertheless, we need some workaround.  Given that the previous
behaviour was not to strip, I think we can reuse that for broken toolchains?

~Andrew

Re: [PATCH v8] xen: Strip xen.efi by default
Posted by Frediano Ziglio 2 months, 3 weeks ago
On Fri, 14 Nov 2025 at 19:18, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>
> On 14/11/2025 3:40 pm, Oleksii Kurochko wrote:
> >
> >
> > On 11/13/25 4:43 PM, Frediano Ziglio wrote:
> >> From: Frediano Ziglio <frediano.ziglio@cloud.com>
> >>
> >> For xen.gz file we strip all symbols and have an additional
> >> xen-syms.efi file version with all symbols.
> >> Make xen.efi more coherent stripping all symbols too.
> >> xen-syms.efi can be used for debugging.
> >>
> >> Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
> > Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> >
> > Thanks.
>
> Thanks.  Unfortunately CI says no.
>
> Ubuntu's 20.04, 18.04 and 16.04 all fail:
> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2159622869
>
> From 16.04:
>
> 2025-11-14T18:01:51.192964Z 01O strip xen-syms.efi -o xen.efi
> 2025-11-14T18:01:51.198151Z 01O strip:xen-syms.efi[.init]: relocation count is negative: File truncated
> 2025-11-14T18:01:51.198166Z 01O strip: xen.efi: Failed to read debug data section
> 2025-11-14T18:01:51.198169Z 01O strip:xen.efi: error copying private BFD data: File truncated
> 2025-11-14T18:01:51.198932Z 01O arch/x86/Makefile:207: recipe for target 'xen.efi' failed
> 2025-11-14T18:01:51.198937Z 01O make[3]: *** [xen.efi] Error 1
> 2025-11-14T18:01:51.199616Z 01O build.mk:90: recipe for target 'xen' failed
> 2025-11-14T18:01:51.199619Z 01O make[2]: *** [xen] Error 2
> 2025-11-14T18:01:51.200402Z 01O Makefile:600: recipe for target 'xen' failed
> 2025-11-14T18:01:51.200409Z 01O make[1]: *** [xen] Error 2
>
>
> I find it hard to believe that the relocation count is really negative,
> and given that newer binuitls works, I expect this is a binutils bug.
>

Unless the message is just misleading I find it hard to have a
negative number of items in a container.

> Nevertheless, we need some workaround.  Given that the previous
> behaviour was not to strip, I think we can reuse that for broken toolchains?
>

Something like that ?

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index a154ffe6b2..c465eb12e2 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -236,7 +236,9 @@ ifeq ($(CONFIG_DEBUG_INFO),y)
        $(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) \
                -O elf64-x86-64 $(TARGET)-syms.efi $@.elf
 endif
-       $(STRIP) $(TARGET)-syms.efi -o $@
+       $(STRIP) $(TARGET)-syms.efi -o $@ || { \
+               LANG=C strip $(TARGET)-syms.efi -o $@ 2>&1 | grep -q \
+               "relocation count is negative" && mv -f $(TARGET)-syms.efi $@; }
 ifneq ($(CONFIG_DEBUG_INFO),y)
        rm -f $(TARGET)-syms.efi
 endif

It will fall back to not stripping in case that bug is detected. I
don't know how to test it.
(the LANG=C is to always force the English message).

> ~Andrew

Frediano
Re: [PATCH v8] xen: Strip xen.efi by default
Posted by Frediano Ziglio 2 months, 2 weeks ago
On Sat, 15 Nov 2025 at 06:23, Frediano Ziglio <freddy77@gmail.com> wrote:
>
> On Fri, 14 Nov 2025 at 19:18, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> >
> > On 14/11/2025 3:40 pm, Oleksii Kurochko wrote:
> > >
> > >
> > > On 11/13/25 4:43 PM, Frediano Ziglio wrote:
> > >> From: Frediano Ziglio <frediano.ziglio@cloud.com>
> > >>
> > >> For xen.gz file we strip all symbols and have an additional
> > >> xen-syms.efi file version with all symbols.
> > >> Make xen.efi more coherent stripping all symbols too.
> > >> xen-syms.efi can be used for debugging.
> > >>
> > >> Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
> > > Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> > >
> > > Thanks.
> >
> > Thanks.  Unfortunately CI says no.
> >
> > Ubuntu's 20.04, 18.04 and 16.04 all fail:
> > https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2159622869
> >
> > From 16.04:
> >
> > 2025-11-14T18:01:51.192964Z 01O strip xen-syms.efi -o xen.efi
> > 2025-11-14T18:01:51.198151Z 01O strip:xen-syms.efi[.init]: relocation count is negative: File truncated
> > 2025-11-14T18:01:51.198166Z 01O strip: xen.efi: Failed to read debug data section
> > 2025-11-14T18:01:51.198169Z 01O strip:xen.efi: error copying private BFD data: File truncated
> > 2025-11-14T18:01:51.198932Z 01O arch/x86/Makefile:207: recipe for target 'xen.efi' failed
> > 2025-11-14T18:01:51.198937Z 01O make[3]: *** [xen.efi] Error 1
> > 2025-11-14T18:01:51.199616Z 01O build.mk:90: recipe for target 'xen' failed
> > 2025-11-14T18:01:51.199619Z 01O make[2]: *** [xen] Error 2
> > 2025-11-14T18:01:51.200402Z 01O Makefile:600: recipe for target 'xen' failed
> > 2025-11-14T18:01:51.200409Z 01O make[1]: *** [xen] Error 2
> >
> >
> > I find it hard to believe that the relocation count is really negative,
> > and given that newer binuitls works, I expect this is a binutils bug.
> >
>
> Unless the message is just misleading I find it hard to have a
> negative number of items in a container.
>
> > Nevertheless, we need some workaround.  Given that the previous
> > behaviour was not to strip, I think we can reuse that for broken toolchains?
> >
>
> Something like that ?
>
> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> index a154ffe6b2..c465eb12e2 100644
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -236,7 +236,9 @@ ifeq ($(CONFIG_DEBUG_INFO),y)
>         $(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) \
>                 -O elf64-x86-64 $(TARGET)-syms.efi $@.elf
>  endif
> -       $(STRIP) $(TARGET)-syms.efi -o $@
> +       $(STRIP) $(TARGET)-syms.efi -o $@ || { \
> +               LANG=C strip $(TARGET)-syms.efi -o $@ 2>&1 | grep -q \
> +               "relocation count is negative" && mv -f $(TARGET)-syms.efi $@; }
>  ifneq ($(CONFIG_DEBUG_INFO),y)
>         rm -f $(TARGET)-syms.efi
>  endif
>
> It will fall back to not stripping in case that bug is detected. I
> don't know how to test it.
> (the LANG=C is to always force the English message).
>

It looks like this change works better and CI is happy.
It duplicates the linking with -s option if the strip fails.
Yes, it's a hack and almost duplicates the one command above.
What about it?

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index a154ffe6b2..5f5162841e 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -236,7 +236,10 @@ ifeq ($(CONFIG_DEBUG_INFO),y)
        $(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) \
                -O elf64-x86-64 $(TARGET)-syms.efi $@.elf
 endif
-       $(STRIP) $(TARGET)-syms.efi -o $@
+       $(STRIP) $(TARGET)-syms.efi -o $@ || \
+       $(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T $(obj)/efi.lds $< \
+             $(dot-target).1r.o $(dot-target).1s.o $(orphan-handling-y) \
+             $(note_file_option) -s -o $@
 ifneq ($(CONFIG_DEBUG_INFO),y)
        rm -f $(TARGET)-syms.efi
 endif

Frediano
Re: [PATCH v8] xen: Strip xen.efi by default
Posted by Marek Marczykowski-Górecki 2 months, 2 weeks ago
On Thu, Nov 20, 2025 at 01:59:24PM +0000, Frediano Ziglio wrote:
> On Sat, 15 Nov 2025 at 06:23, Frediano Ziglio <freddy77@gmail.com> wrote:
> >
> > On Fri, 14 Nov 2025 at 19:18, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> > >
> > > On 14/11/2025 3:40 pm, Oleksii Kurochko wrote:
> > > >
> > > >
> > > > On 11/13/25 4:43 PM, Frediano Ziglio wrote:
> > > >> From: Frediano Ziglio <frediano.ziglio@cloud.com>
> > > >>
> > > >> For xen.gz file we strip all symbols and have an additional
> > > >> xen-syms.efi file version with all symbols.
> > > >> Make xen.efi more coherent stripping all symbols too.
> > > >> xen-syms.efi can be used for debugging.
> > > >>
> > > >> Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
> > > > Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> > > >
> > > > Thanks.
> > >
> > > Thanks.  Unfortunately CI says no.
> > >
> > > Ubuntu's 20.04, 18.04 and 16.04 all fail:
> > > https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2159622869
> > >
> > > From 16.04:
> > >
> > > 2025-11-14T18:01:51.192964Z 01O strip xen-syms.efi -o xen.efi
> > > 2025-11-14T18:01:51.198151Z 01O strip:xen-syms.efi[.init]: relocation count is negative: File truncated
> > > 2025-11-14T18:01:51.198166Z 01O strip: xen.efi: Failed to read debug data section
> > > 2025-11-14T18:01:51.198169Z 01O strip:xen.efi: error copying private BFD data: File truncated
> > > 2025-11-14T18:01:51.198932Z 01O arch/x86/Makefile:207: recipe for target 'xen.efi' failed
> > > 2025-11-14T18:01:51.198937Z 01O make[3]: *** [xen.efi] Error 1
> > > 2025-11-14T18:01:51.199616Z 01O build.mk:90: recipe for target 'xen' failed
> > > 2025-11-14T18:01:51.199619Z 01O make[2]: *** [xen] Error 2
> > > 2025-11-14T18:01:51.200402Z 01O Makefile:600: recipe for target 'xen' failed
> > > 2025-11-14T18:01:51.200409Z 01O make[1]: *** [xen] Error 2
> > >
> > >
> > > I find it hard to believe that the relocation count is really negative,
> > > and given that newer binuitls works, I expect this is a binutils bug.
> > >
> >
> > Unless the message is just misleading I find it hard to have a
> > negative number of items in a container.
> >
> > > Nevertheless, we need some workaround.  Given that the previous
> > > behaviour was not to strip, I think we can reuse that for broken toolchains?
> > >
> >
> > Something like that ?
> >
> > diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> > index a154ffe6b2..c465eb12e2 100644
> > --- a/xen/arch/x86/Makefile
> > +++ b/xen/arch/x86/Makefile
> > @@ -236,7 +236,9 @@ ifeq ($(CONFIG_DEBUG_INFO),y)
> >         $(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) \
> >                 -O elf64-x86-64 $(TARGET)-syms.efi $@.elf
> >  endif
> > -       $(STRIP) $(TARGET)-syms.efi -o $@
> > +       $(STRIP) $(TARGET)-syms.efi -o $@ || { \
> > +               LANG=C strip $(TARGET)-syms.efi -o $@ 2>&1 | grep -q \
> > +               "relocation count is negative" && mv -f $(TARGET)-syms.efi $@; }
> >  ifneq ($(CONFIG_DEBUG_INFO),y)
> >         rm -f $(TARGET)-syms.efi
> >  endif
> >
> > It will fall back to not stripping in case that bug is detected. I
> > don't know how to test it.
> > (the LANG=C is to always force the English message).
> >
> 
> It looks like this change works better and CI is happy.
> It duplicates the linking with -s option if the strip fails.
> Yes, it's a hack and almost duplicates the one command above.
> What about it?

Is it guaranteed to match xen-syms.efi?

There is an alternative option: based on observation that Ubuntu 16.04
runs out of support in April 2026 - which is before Xen 4.22 release,
maybe we can drop that test from CI already?

> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> index a154ffe6b2..5f5162841e 100644
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -236,7 +236,10 @@ ifeq ($(CONFIG_DEBUG_INFO),y)
>         $(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) \
>                 -O elf64-x86-64 $(TARGET)-syms.efi $@.elf
>  endif
> -       $(STRIP) $(TARGET)-syms.efi -o $@
> +       $(STRIP) $(TARGET)-syms.efi -o $@ || \
> +       $(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T $(obj)/efi.lds $< \
> +             $(dot-target).1r.o $(dot-target).1s.o $(orphan-handling-y) \
> +             $(note_file_option) -s -o $@
>  ifneq ($(CONFIG_DEBUG_INFO),y)
>         rm -f $(TARGET)-syms.efi
>  endif
> 
> Frediano

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
Re: [PATCH v8] xen: Strip xen.efi by default
Posted by Frediano Ziglio 2 months, 2 weeks ago
On Thu, 20 Nov 2025 at 14:05, Marek Marczykowski-Górecki
<marmarek@invisiblethingslab.com> wrote:
>
> On Thu, Nov 20, 2025 at 01:59:24PM +0000, Frediano Ziglio wrote:
> > On Sat, 15 Nov 2025 at 06:23, Frediano Ziglio <freddy77@gmail.com> wrote:
> > >
> > > On Fri, 14 Nov 2025 at 19:18, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> > > >
> > > > On 14/11/2025 3:40 pm, Oleksii Kurochko wrote:
> > > > >
> > > > >
> > > > > On 11/13/25 4:43 PM, Frediano Ziglio wrote:
> > > > >> From: Frediano Ziglio <frediano.ziglio@cloud.com>
> > > > >>
> > > > >> For xen.gz file we strip all symbols and have an additional
> > > > >> xen-syms.efi file version with all symbols.
> > > > >> Make xen.efi more coherent stripping all symbols too.
> > > > >> xen-syms.efi can be used for debugging.
> > > > >>
> > > > >> Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
> > > > > Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> > > > >
> > > > > Thanks.
> > > >
> > > > Thanks.  Unfortunately CI says no.
> > > >
> > > > Ubuntu's 20.04, 18.04 and 16.04 all fail:
> > > > https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2159622869
> > > >
> > > > From 16.04:
> > > >
> > > > 2025-11-14T18:01:51.192964Z 01O strip xen-syms.efi -o xen.efi
> > > > 2025-11-14T18:01:51.198151Z 01O strip:xen-syms.efi[.init]: relocation count is negative: File truncated
> > > > 2025-11-14T18:01:51.198166Z 01O strip: xen.efi: Failed to read debug data section
> > > > 2025-11-14T18:01:51.198169Z 01O strip:xen.efi: error copying private BFD data: File truncated
> > > > 2025-11-14T18:01:51.198932Z 01O arch/x86/Makefile:207: recipe for target 'xen.efi' failed
> > > > 2025-11-14T18:01:51.198937Z 01O make[3]: *** [xen.efi] Error 1
> > > > 2025-11-14T18:01:51.199616Z 01O build.mk:90: recipe for target 'xen' failed
> > > > 2025-11-14T18:01:51.199619Z 01O make[2]: *** [xen] Error 2
> > > > 2025-11-14T18:01:51.200402Z 01O Makefile:600: recipe for target 'xen' failed
> > > > 2025-11-14T18:01:51.200409Z 01O make[1]: *** [xen] Error 2
> > > >
> > > >
> > > > I find it hard to believe that the relocation count is really negative,
> > > > and given that newer binuitls works, I expect this is a binutils bug.
> > > >
> > >
> > > Unless the message is just misleading I find it hard to have a
> > > negative number of items in a container.
> > >
> > > > Nevertheless, we need some workaround.  Given that the previous
> > > > behaviour was not to strip, I think we can reuse that for broken toolchains?
> > > >
> > >
> > > Something like that ?
> > >
> > > diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> > > index a154ffe6b2..c465eb12e2 100644
> > > --- a/xen/arch/x86/Makefile
> > > +++ b/xen/arch/x86/Makefile
> > > @@ -236,7 +236,9 @@ ifeq ($(CONFIG_DEBUG_INFO),y)
> > >         $(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) \
> > >                 -O elf64-x86-64 $(TARGET)-syms.efi $@.elf
> > >  endif
> > > -       $(STRIP) $(TARGET)-syms.efi -o $@
> > > +       $(STRIP) $(TARGET)-syms.efi -o $@ || { \
> > > +               LANG=C strip $(TARGET)-syms.efi -o $@ 2>&1 | grep -q \
> > > +               "relocation count is negative" && mv -f $(TARGET)-syms.efi $@; }
> > >  ifneq ($(CONFIG_DEBUG_INFO),y)
> > >         rm -f $(TARGET)-syms.efi
> > >  endif
> > >
> > > It will fall back to not stripping in case that bug is detected. I
> > > don't know how to test it.
> > > (the LANG=C is to always force the English message).
> > >
> >
> > It looks like this change works better and CI is happy.
> > It duplicates the linking with -s option if the strip fails.
> > Yes, it's a hack and almost duplicates the one command above.
> > What about it?
>
> Is it guaranteed to match xen-syms.efi?
>
> There is an alternative option: based on observation that Ubuntu 16.04
> runs out of support in April 2026 - which is before Xen 4.22 release,
> maybe we can drop that test from CI already?
>

That would work too.

Looking a bit more at the logs from
https://gitlab.com/xen-project/people/fziglio/xen/-/jobs/12158955130/viewer
there's something that worries me about.
I added "ls -l" and "objdump -x" of the output file and objdump is
complaining about relocations more or less the same strip was
complaining about:

    RELOCATION RECORDS FOR [.init]:
    objdump: failed to read relocs in: xen-syms.efi
    objdump: error message was: File truncated

not counting some weird relocations:

    reloc 2060 offset    0 [a4b8a4b0] UNKNOWN

    reloc 2294 offset    0 [a4b8a4b0] HIGHADJ (  80)

    reloc 2348 offset    0 [a4b8a4b0] SECTION

    reloc 2372 offset    0 [a4b8a4b0] RESERVED1

    reloc 2730 offset    0 [a4b8a4b0] MIPS_JMPADDR

Maybe the CI now is happy but there's not much point if the produced
files are not working.

> > diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> > index a154ffe6b2..5f5162841e 100644
> > --- a/xen/arch/x86/Makefile
> > +++ b/xen/arch/x86/Makefile
> > @@ -236,7 +236,10 @@ ifeq ($(CONFIG_DEBUG_INFO),y)
> >         $(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) \
> >                 -O elf64-x86-64 $(TARGET)-syms.efi $@.elf
> >  endif
> > -       $(STRIP) $(TARGET)-syms.efi -o $@
> > +       $(STRIP) $(TARGET)-syms.efi -o $@ || \
> > +       $(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T $(obj)/efi.lds $< \
> > +             $(dot-target).1r.o $(dot-target).1s.o $(orphan-handling-y) \
> > +             $(note_file_option) -s -o $@
> >  ifneq ($(CONFIG_DEBUG_INFO),y)
> >         rm -f $(TARGET)-syms.efi
> >  endif
> >
Re: [PATCH v8] xen: Strip xen.efi by default
Posted by Jan Beulich 2 months, 2 weeks ago
On 20.11.2025 14:59, Frediano Ziglio wrote:
> On Sat, 15 Nov 2025 at 06:23, Frediano Ziglio <freddy77@gmail.com> wrote:
>>
>> On Fri, 14 Nov 2025 at 19:18, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>>
>>> On 14/11/2025 3:40 pm, Oleksii Kurochko wrote:
>>>>
>>>>
>>>> On 11/13/25 4:43 PM, Frediano Ziglio wrote:
>>>>> From: Frediano Ziglio <frediano.ziglio@cloud.com>
>>>>>
>>>>> For xen.gz file we strip all symbols and have an additional
>>>>> xen-syms.efi file version with all symbols.
>>>>> Make xen.efi more coherent stripping all symbols too.
>>>>> xen-syms.efi can be used for debugging.
>>>>>
>>>>> Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
>>>> Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
>>>>
>>>> Thanks.
>>>
>>> Thanks.  Unfortunately CI says no.
>>>
>>> Ubuntu's 20.04, 18.04 and 16.04 all fail:
>>> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2159622869
>>>
>>> From 16.04:
>>>
>>> 2025-11-14T18:01:51.192964Z 01O strip xen-syms.efi -o xen.efi
>>> 2025-11-14T18:01:51.198151Z 01O strip:xen-syms.efi[.init]: relocation count is negative: File truncated
>>> 2025-11-14T18:01:51.198166Z 01O strip: xen.efi: Failed to read debug data section
>>> 2025-11-14T18:01:51.198169Z 01O strip:xen.efi: error copying private BFD data: File truncated
>>> 2025-11-14T18:01:51.198932Z 01O arch/x86/Makefile:207: recipe for target 'xen.efi' failed
>>> 2025-11-14T18:01:51.198937Z 01O make[3]: *** [xen.efi] Error 1
>>> 2025-11-14T18:01:51.199616Z 01O build.mk:90: recipe for target 'xen' failed
>>> 2025-11-14T18:01:51.199619Z 01O make[2]: *** [xen] Error 2
>>> 2025-11-14T18:01:51.200402Z 01O Makefile:600: recipe for target 'xen' failed
>>> 2025-11-14T18:01:51.200409Z 01O make[1]: *** [xen] Error 2
>>>
>>>
>>> I find it hard to believe that the relocation count is really negative,
>>> and given that newer binuitls works, I expect this is a binutils bug.
>>>
>>
>> Unless the message is just misleading I find it hard to have a
>> negative number of items in a container.
>>
>>> Nevertheless, we need some workaround.  Given that the previous
>>> behaviour was not to strip, I think we can reuse that for broken toolchains?
>>>
>>
>> Something like that ?
>>
>> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
>> index a154ffe6b2..c465eb12e2 100644
>> --- a/xen/arch/x86/Makefile
>> +++ b/xen/arch/x86/Makefile
>> @@ -236,7 +236,9 @@ ifeq ($(CONFIG_DEBUG_INFO),y)
>>         $(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) \
>>                 -O elf64-x86-64 $(TARGET)-syms.efi $@.elf
>>  endif
>> -       $(STRIP) $(TARGET)-syms.efi -o $@
>> +       $(STRIP) $(TARGET)-syms.efi -o $@ || { \
>> +               LANG=C strip $(TARGET)-syms.efi -o $@ 2>&1 | grep -q \
>> +               "relocation count is negative" && mv -f $(TARGET)-syms.efi $@; }
>>  ifneq ($(CONFIG_DEBUG_INFO),y)
>>         rm -f $(TARGET)-syms.efi
>>  endif
>>
>> It will fall back to not stripping in case that bug is detected. I
>> don't know how to test it.
>> (the LANG=C is to always force the English message).
>>
> 
> It looks like this change works better and CI is happy.
> It duplicates the linking with -s option if the strip fails.
> Yes, it's a hack and almost duplicates the one command above.
> What about it?

As alluded to elsewhere - can't we detect the situation and avoid linking
with debug info included in that case, like we already do for other reasons?
Linking xen.efi is quite a bit slower than linking xen-syms, so the extra
linking pass would better be avoided imo.

Jan

> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -236,7 +236,10 @@ ifeq ($(CONFIG_DEBUG_INFO),y)
>         $(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) \
>                 -O elf64-x86-64 $(TARGET)-syms.efi $@.elf
>  endif
> -       $(STRIP) $(TARGET)-syms.efi -o $@
> +       $(STRIP) $(TARGET)-syms.efi -o $@ || \
> +       $(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T $(obj)/efi.lds $< \
> +             $(dot-target).1r.o $(dot-target).1s.o $(orphan-handling-y) \
> +             $(note_file_option) -s -o $@
>  ifneq ($(CONFIG_DEBUG_INFO),y)
>         rm -f $(TARGET)-syms.efi
>  endif
> 
> Frediano
Re: [PATCH v8] xen: Strip xen.efi by default
Posted by Marek Marczykowski-Górecki 2 months, 2 weeks ago
On Sat, Nov 15, 2025 at 06:23:08AM +0000, Frediano Ziglio wrote:
> On Fri, 14 Nov 2025 at 19:18, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> >
> > On 14/11/2025 3:40 pm, Oleksii Kurochko wrote:
> > >
> > >
> > > On 11/13/25 4:43 PM, Frediano Ziglio wrote:
> > >> From: Frediano Ziglio <frediano.ziglio@cloud.com>
> > >>
> > >> For xen.gz file we strip all symbols and have an additional
> > >> xen-syms.efi file version with all symbols.
> > >> Make xen.efi more coherent stripping all symbols too.
> > >> xen-syms.efi can be used for debugging.
> > >>
> > >> Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
> > > Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> > >
> > > Thanks.
> >
> > Thanks.  Unfortunately CI says no.
> >
> > Ubuntu's 20.04, 18.04 and 16.04 all fail:
> > https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2159622869
> >
> > From 16.04:
> >
> > 2025-11-14T18:01:51.192964Z 01O strip xen-syms.efi -o xen.efi
> > 2025-11-14T18:01:51.198151Z 01O strip:xen-syms.efi[.init]: relocation count is negative: File truncated
> > 2025-11-14T18:01:51.198166Z 01O strip: xen.efi: Failed to read debug data section
> > 2025-11-14T18:01:51.198169Z 01O strip:xen.efi: error copying private BFD data: File truncated
> > 2025-11-14T18:01:51.198932Z 01O arch/x86/Makefile:207: recipe for target 'xen.efi' failed
> > 2025-11-14T18:01:51.198937Z 01O make[3]: *** [xen.efi] Error 1
> > 2025-11-14T18:01:51.199616Z 01O build.mk:90: recipe for target 'xen' failed
> > 2025-11-14T18:01:51.199619Z 01O make[2]: *** [xen] Error 2
> > 2025-11-14T18:01:51.200402Z 01O Makefile:600: recipe for target 'xen' failed
> > 2025-11-14T18:01:51.200409Z 01O make[1]: *** [xen] Error 2
> >
> >
> > I find it hard to believe that the relocation count is really negative,
> > and given that newer binuitls works, I expect this is a binutils bug.
> >
> 
> Unless the message is just misleading I find it hard to have a
> negative number of items in a container.
> 
> > Nevertheless, we need some workaround.  Given that the previous
> > behaviour was not to strip, I think we can reuse that for broken toolchains?
> >
> 
> Something like that ?
> 
> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> index a154ffe6b2..c465eb12e2 100644
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -236,7 +236,9 @@ ifeq ($(CONFIG_DEBUG_INFO),y)
>         $(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) \
>                 -O elf64-x86-64 $(TARGET)-syms.efi $@.elf
>  endif
> -       $(STRIP) $(TARGET)-syms.efi -o $@
> +       $(STRIP) $(TARGET)-syms.efi -o $@ || { \
> +               LANG=C strip $(TARGET)-syms.efi -o $@ 2>&1 | grep -q \
> +               "relocation count is negative" && mv -f $(TARGET)-syms.efi $@; }
>  ifneq ($(CONFIG_DEBUG_INFO),y)
>         rm -f $(TARGET)-syms.efi
>  endif

On Ubuntu 20.04 it fails different way:

    strip: xen.efi: Data Directory size (1c) exceeds space left in section (18)
    strip: xen.efi: error copying private BFD data: file in wrong format

Looks similar to:
https://lore.kernel.org/all/3TMd7J2u5gCA8ouIG_Xfcw7s5JKMG06XsDIesEB3Fi9htUJ43Lfl057wXohlpCHcszqoCmicpIlneEDO26ZqT8QfC2Y39VxBuqD3nS1j5Q4=@trmm.net/

Qubes has this patch:
https://github.com/QubesOS/qubes-vmm-xen/blob/main/0608-Fix-buildid-alignment.patch

    diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
    index 9a1dfe1b340a..26a23a7b0651 100644
    --- a/xen/arch/x86/xen.lds.S
    +++ b/xen/arch/x86/xen.lds.S
    @@ -171,6 +171,7 @@ SECTIONS
            __note_gnu_build_id_end = .;
       } PHDR(note) PHDR(text)
     #elif defined(BUILD_ID_EFI)
    +  . = ALIGN(32);
       DECL_SECTION(.buildid) {
            __note_gnu_build_id_start = .;
            *(.buildid)

Lets see if that helps:
https://gitlab.com/xen-project/people/marmarek/xen/-/pipelines/2167783980

And few lines earlier there is also:

    ld: xen-syms.efi: warning: section .init: alignment 2**15 not representable

> It will fall back to not stripping in case that bug is detected. I
> don't know how to test it.
> (the LANG=C is to always force the English message).

If going this way, use LC_ALL=C (otherwise LC_ALL=something present in
the env would override your LANG=C). But given there are different
messages, this may not be the best option.

And TBH, I don't like silent behavior change based on (unknown) version
of binutils. Lets see if the alignment adjustment helps. While it
shouldn't be necessary on newer binutils (thanks to Jan's fix there -
see thread linked above), IMO it isn't too bad to add it, to keep older
versions happy. And it can be dropped, once we raise toolchain base
version next time.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
Re: [PATCH v8] xen: Strip xen.efi by default
Posted by Andrew Cooper 2 months, 2 weeks ago
On 19/11/2025 3:06 pm, Marek Marczykowski-Górecki wrote:
> On Sat, Nov 15, 2025 at 06:23:08AM +0000, Frediano Ziglio wrote:
>> On Fri, 14 Nov 2025 at 19:18, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>> On 14/11/2025 3:40 pm, Oleksii Kurochko wrote:
>>>>
>>>> On 11/13/25 4:43 PM, Frediano Ziglio wrote:
>>>>> From: Frediano Ziglio <frediano.ziglio@cloud.com>
>>>>>
>>>>> For xen.gz file we strip all symbols and have an additional
>>>>> xen-syms.efi file version with all symbols.
>>>>> Make xen.efi more coherent stripping all symbols too.
>>>>> xen-syms.efi can be used for debugging.
>>>>>
>>>>> Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
>>>> Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
>>>>
>>>> Thanks.
>>> Thanks.  Unfortunately CI says no.
>>>
>>> Ubuntu's 20.04, 18.04 and 16.04 all fail:
>>> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2159622869
>>>
>>> From 16.04:
>>>
>>> 2025-11-14T18:01:51.192964Z 01O strip xen-syms.efi -o xen.efi
>>> 2025-11-14T18:01:51.198151Z 01O strip:xen-syms.efi[.init]: relocation count is negative: File truncated
>>> 2025-11-14T18:01:51.198166Z 01O strip: xen.efi: Failed to read debug data section
>>> 2025-11-14T18:01:51.198169Z 01O strip:xen.efi: error copying private BFD data: File truncated
>>> 2025-11-14T18:01:51.198932Z 01O arch/x86/Makefile:207: recipe for target 'xen.efi' failed
>>> 2025-11-14T18:01:51.198937Z 01O make[3]: *** [xen.efi] Error 1
>>> 2025-11-14T18:01:51.199616Z 01O build.mk:90: recipe for target 'xen' failed
>>> 2025-11-14T18:01:51.199619Z 01O make[2]: *** [xen] Error 2
>>> 2025-11-14T18:01:51.200402Z 01O Makefile:600: recipe for target 'xen' failed
>>> 2025-11-14T18:01:51.200409Z 01O make[1]: *** [xen] Error 2
>>>
>>>
>>> I find it hard to believe that the relocation count is really negative,
>>> and given that newer binuitls works, I expect this is a binutils bug.
>>>
>> Unless the message is just misleading I find it hard to have a
>> negative number of items in a container.
>>
>>> Nevertheless, we need some workaround.  Given that the previous
>>> behaviour was not to strip, I think we can reuse that for broken toolchains?
>>>
>> Something like that ?
>>
>> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
>> index a154ffe6b2..c465eb12e2 100644
>> --- a/xen/arch/x86/Makefile
>> +++ b/xen/arch/x86/Makefile
>> @@ -236,7 +236,9 @@ ifeq ($(CONFIG_DEBUG_INFO),y)
>>         $(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) \
>>                 -O elf64-x86-64 $(TARGET)-syms.efi $@.elf
>>  endif
>> -       $(STRIP) $(TARGET)-syms.efi -o $@
>> +       $(STRIP) $(TARGET)-syms.efi -o $@ || { \
>> +               LANG=C strip $(TARGET)-syms.efi -o $@ 2>&1 | grep -q \
>> +               "relocation count is negative" && mv -f $(TARGET)-syms.efi $@; }
>>  ifneq ($(CONFIG_DEBUG_INFO),y)
>>         rm -f $(TARGET)-syms.efi
>>  endif
> On Ubuntu 20.04 it fails different way:
>
>     strip: xen.efi: Data Directory size (1c) exceeds space left in section (18)
>     strip: xen.efi: error copying private BFD data: file in wrong format
>
> Looks similar to:
> https://lore.kernel.org/all/3TMd7J2u5gCA8ouIG_Xfcw7s5JKMG06XsDIesEB3Fi9htUJ43Lfl057wXohlpCHcszqoCmicpIlneEDO26ZqT8QfC2Y39VxBuqD3nS1j5Q4=@trmm.net/
>
> Qubes has this patch:
> https://github.com/QubesOS/qubes-vmm-xen/blob/main/0608-Fix-buildid-alignment.patch
>
>     diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
>     index 9a1dfe1b340a..26a23a7b0651 100644
>     --- a/xen/arch/x86/xen.lds.S
>     +++ b/xen/arch/x86/xen.lds.S
>     @@ -171,6 +171,7 @@ SECTIONS
>             __note_gnu_build_id_end = .;
>        } PHDR(note) PHDR(text)
>      #elif defined(BUILD_ID_EFI)
>     +  . = ALIGN(32);
>        DECL_SECTION(.buildid) {
>             __note_gnu_build_id_start = .;
>             *(.buildid)
>
> Lets see if that helps:
> https://gitlab.com/xen-project/people/marmarek/xen/-/pipelines/2167783980

That seems to have fixed 20.04 and 18.04.

The extra line wants a comment at least identifying roughly which
binutils it's a workaround for, so we can drop it eventually.

And, as it's already in a downstream, it should be upstreamed and
backported.

>
> And few lines earlier there is also:
>
>     ld: xen-syms.efi: warning: section .init: alignment 2**15 not representable

This can't be helped.  It's not an error, but you also cant get LD to
shut up about it.

>
>> It will fall back to not stripping in case that bug is detected. I
>> don't know how to test it.
>> (the LANG=C is to always force the English message).
> If going this way, use LC_ALL=C (otherwise LC_ALL=something present in
> the env would override your LANG=C). But given there are different
> messages, this may not be the best option.
>
> And TBH, I don't like silent behavior change based on (unknown) version
> of binutils. Lets see if the alignment adjustment helps. While it
> shouldn't be necessary on newer binutils (thanks to Jan's fix there -
> see thread linked above), IMO it isn't too bad to add it, to keep older
> versions happy. And it can be dropped, once we raise toolchain base
> version next time.

Given it's now only 16.04 broken, how about simply excluding xen.efi
with these broken toolchains?

~Andrew

Re: [PATCH v8] xen: Strip xen.efi by default
Posted by Marek Marczykowski-Górecki 2 months, 2 weeks ago
On Wed, Nov 19, 2025 at 04:02:30PM +0000, Andrew Cooper wrote:
> Given it's now only 16.04 broken, how about simply excluding xen.efi
> with these broken toolchains?

That would mean adjusting README to say a newer binutils is required for
xen.efi, right? Then ofc we would need to figure out which version
specifically. FWIW Ubuntu 16.04 has 2.26 and Ubuntu 18.04 has 2.30.
Would raising required toolchain version (for some configuration here)
even accepted, especially if considered for backporting?

Alternatively, simply disable building xen.efi in CI on 16.04, and maybe
document as "known issue" pointing at toolchain bug? Result is very
similar, but might be more acceptable on the process side...

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
Re: [PATCH v8] xen: Strip xen.efi by default
Posted by Jan Beulich 2 months, 2 weeks ago
On 19.11.2025 18:08, Marek Marczykowski-Górecki wrote:
> On Wed, Nov 19, 2025 at 04:02:30PM +0000, Andrew Cooper wrote:
>> Given it's now only 16.04 broken, how about simply excluding xen.efi
>> with these broken toolchains?
> 
> That would mean adjusting README to say a newer binutils is required for
> xen.efi, right? Then ofc we would need to figure out which version
> specifically. FWIW Ubuntu 16.04 has 2.26 and Ubuntu 18.04 has 2.30.
> Would raising required toolchain version (for some configuration here)
> even accepted, especially if considered for backporting?
> 
> Alternatively, simply disable building xen.efi in CI on 16.04, and maybe
> document as "known issue" pointing at toolchain bug? Result is very
> similar, but might be more acceptable on the process side...

Along the lines of what Andrew said, the probing done would then want
updating. Which in turn raises the need to properly know what to probe.
That said, from what I've read so far it's not the building of xen.efi
which would need disabling, but (as we already do for certain cases)
its building with debug info included (which in turn is now going to
require its stripping during the build process).

Jan

Re: [PATCH v8] xen: Strip xen.efi by default
Posted by Andrew Cooper 2 months, 2 weeks ago
On 19/11/2025 5:08 pm, Marek Marczykowski-Górecki wrote:
> On Wed, Nov 19, 2025 at 04:02:30PM +0000, Andrew Cooper wrote:
>> Given it's now only 16.04 broken, how about simply excluding xen.efi
>> with these broken toolchains?
> That would mean adjusting README to say a newer binutils is required for
> xen.efi, right? Then ofc we would need to figure out which version
> specifically. FWIW Ubuntu 16.04 has 2.26 and Ubuntu 18.04 has 2.30.
> Would raising required toolchain version (for some configuration here)
> even accepted, especially if considered for backporting?
>
> Alternatively, simply disable building xen.efi in CI on 16.04, and maybe
> document as "known issue" pointing at toolchain bug? Result is very
> similar, but might be more acceptable on the process side...

xen.efi has never been part of the toolchain minimum statement.

It was introduced as unconditionally enabled, with probing of the
toolchain to decide whether it was capable or not. That's what
XEN_BUILD_EFI is doing.

~Andrew

Re: [PATCH v8] xen: Strip xen.efi by default
Posted by Marek Marczykowski-Górecki 2 months, 3 weeks ago
On Thu, Nov 13, 2025 at 03:43:58PM +0000, Frediano Ziglio wrote:
> From: Frediano Ziglio <frediano.ziglio@cloud.com>
> 
> For xen.gz file we strip all symbols and have an additional
> xen-syms.efi file version with all symbols.

You meant xen-syms here, right?

> Make xen.efi more coherent stripping all symbols too.
> xen-syms.efi can be used for debugging.
> 
> Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>

With the above fixed:

Reviewed-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
Re: [PATCH for-4.21 v8] xen: Strip xen.efi by default
Posted by Andrew Cooper 2 months, 3 weeks ago
On 13/11/2025 6:35 pm, Marek Marczykowski-Górecki wrote:
> On Thu, Nov 13, 2025 at 03:43:58PM +0000, Frediano Ziglio wrote:
>> From: Frediano Ziglio <frediano.ziglio@cloud.com>
>>
>> For xen.gz file we strip all symbols and have an additional
>> xen-syms.efi file version with all symbols.
> You meant xen-syms here, right?

I think so.  I just noticed the same.

>
>> Make xen.efi more coherent stripping all symbols too.
>> xen-syms.efi can be used for debugging.
>>
>> Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
> With the above fixed:
>
> Reviewed-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
>

I've done some ad-hoc testing and everything seems to be in order.

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

Re: [PATCH for-4.21 v8] xen: Strip xen.efi by default
Posted by Frediano Ziglio 2 months, 3 weeks ago
On Thu, 13 Nov 2025 at 18:40, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>
> On 13/11/2025 6:35 pm, Marek Marczykowski-Górecki wrote:
> > On Thu, Nov 13, 2025 at 03:43:58PM +0000, Frediano Ziglio wrote:
> >> From: Frediano Ziglio <frediano.ziglio@cloud.com>
> >>
> >> For xen.gz file we strip all symbols and have an additional
> >> xen-syms.efi file version with all symbols.
> > You meant xen-syms here, right?
>
> I think so.  I just noticed the same.
>

Yes, my mistake

> >
> >> Make xen.efi more coherent stripping all symbols too.
> >> xen-syms.efi can be used for debugging.
> >>
> >> Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
> > With the above fixed:
> >
> > Reviewed-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
> >
>
> I've done some ad-hoc testing and everything seems to be in order.
>
> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

Thanks,
   Frediano