Ping: [PATCH] x86/EFI: correct symbol table generation with older GNU ld

[Jan Beulich <jbeulich@xxxxxxxx>]

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

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