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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 29.01.2026 15:44, Daniel P. Smith wrote:
> On 1/21/26 5:05 AM, 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>
>> ---
>> 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).
> 
> Just a suggestion, but do we have the minimal version where the 
> stripping is handled properly? I just think it would be good to have the 
> minimum version documented here. Doing so would make it easier that if 
> the minimum supported build tools are bumped past this version, 
> hopefully someone will either remember or notice the comment and could 
> drop these declarations.

I've changed this to "GNU ld 2.37 and newer strip them, ...". It's always
extra work to dig out version boundaries, and then the other toolchain
(clang/llvm) still isn't covered.

>> +   * 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
> 
> With or without the suggestion,
> 
> Acked-by: Daniel P. Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx>

Thanks.

Jan