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é <roger.pau@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
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