From 7f9cde0f977515d2e108da37c34bdb4f7d69a1cd Mon Sep 17 00:00:00 2001 From: Jan Beulich Date: Wed, 11 Feb 2026 12:21:47 +0100 Subject: [PATCH] x86/EFI: correct symbol table generation with older GNU ld MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit See the extensive code comment. This isn't really nice, but unless I'm overlooking something there doesn't look to be a way to have the linker strip individual symbols while doing its work. Fixes: bf6501a62e80 ("x86-64: EFI boot code") Reported-by: Roger Pau Monné Signed-off-by: Jan Beulich Acked-by: Daniel P. Smith master commit: 45bb2789349b996bef19eeb098b6fe47a2b32f5f master date: 2026-02-02 09:03:05 +0100 --- xen/arch/x86/xen.lds.S | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S index 29de0e7452..95fce0346f 100644 --- a/xen/arch/x86/xen.lds.S +++ b/xen/arch/x86/xen.lds.S @@ -346,6 +346,25 @@ SECTIONS *(.reloc) __base_relocs_end = .; } + + /* + * When efi/relocs-dummy.o is linked into the first-pass binary, the two + * symbols supplied by it (for ./Makefile to use) may appear in the symbol + * table (GNU ld 2.37 and newer strip them, for not being properly + * representable). No such symbols would appear during subsequent passes. + * At least some of those older ld versions emit VIRT_START as absolute, but + * ALT_START as if it was part of .text. The symbols tool generating our + * own symbol table would hence not ignore it when passed --all-symbols, + * leading to the 2nd pass binary having one more symbol than the final (3rd + * pass) one. + * + * Arrange for both (just in case) symbols to always be there, and to always + * be absolute (zero). + */ + PROVIDE(VIRT_START = 0); + PROVIDE(ALT_START = 0); + VIRT_START &= 0; + ALT_START &= 0; #elif defined(XEN_BUILD_EFI) /* * Due to the way EFI support is currently implemented, these two symbols