On 21.01.2026 11:05, Jan Beulich wrote:
> 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]>
This is, afaict, the only left piece which prevents "symbols: check table
sizes don't change between linking passes 2 and 3" from going in. May I
therefore ask for an ack or comments to move this forward?
Thanks, Jan
> ---
> 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
