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é <[email protected]>
Signed-off-by: Jan Beulich <[email protected]>
---
Should we try to somehow avoid the introduction of the two symbols when
using new enough ld, i.e. relocs-dummy.o not needing linking in?
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -339,6 +339,24 @@ 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 (newer linkers 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
