Re: [PATCH v8] xen: Strip xen.efi by default

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 19/11/2025 3:06 pm, Marek Marczykowski-Górecki wrote:
> On Sat, Nov 15, 2025 at 06:23:08AM +0000, Frediano Ziglio wrote:
>> On Fri, 14 Nov 2025 at 19:18, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 
>> wrote:
>>> On 14/11/2025 3:40 pm, Oleksii Kurochko wrote:
>>>>
>>>> On 11/13/25 4:43 PM, Frediano Ziglio wrote:
>>>>> From: Frediano Ziglio <frediano.ziglio@xxxxxxxxx>
>>>>>
>>>>> For xen.gz file we strip all symbols and have an additional
>>>>> xen-syms.efi file version with all symbols.
>>>>> Make xen.efi more coherent stripping all symbols too.
>>>>> xen-syms.efi can be used for debugging.
>>>>>
>>>>> Signed-off-by: Frediano Ziglio <frediano.ziglio@xxxxxxxxx>
>>>> Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>
>>>>
>>>> Thanks.
>>> Thanks.  Unfortunately CI says no.
>>>
>>> Ubuntu's 20.04, 18.04 and 16.04 all fail:
>>> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2159622869
>>>
>>> From 16.04:
>>>
>>> 2025-11-14T18:01:51.192964Z 01O strip xen-syms.efi -o xen.efi
>>> 2025-11-14T18:01:51.198151Z 01O strip:xen-syms.efi[.init]: relocation count 
>>> is negative: File truncated
>>> 2025-11-14T18:01:51.198166Z 01O strip: xen.efi: Failed to read debug data 
>>> section
>>> 2025-11-14T18:01:51.198169Z 01O strip:xen.efi: error copying private BFD 
>>> data: File truncated
>>> 2025-11-14T18:01:51.198932Z 01O arch/x86/Makefile:207: recipe for target 
>>> 'xen.efi' failed
>>> 2025-11-14T18:01:51.198937Z 01O make[3]: *** [xen.efi] Error 1
>>> 2025-11-14T18:01:51.199616Z 01O build.mk:90: recipe for target 'xen' failed
>>> 2025-11-14T18:01:51.199619Z 01O make[2]: *** [xen] Error 2
>>> 2025-11-14T18:01:51.200402Z 01O Makefile:600: recipe for target 'xen' failed
>>> 2025-11-14T18:01:51.200409Z 01O make[1]: *** [xen] Error 2
>>>
>>>
>>> I find it hard to believe that the relocation count is really negative,
>>> and given that newer binuitls works, I expect this is a binutils bug.
>>>
>> Unless the message is just misleading I find it hard to have a
>> negative number of items in a container.
>>
>>> Nevertheless, we need some workaround.  Given that the previous
>>> behaviour was not to strip, I think we can reuse that for broken toolchains?
>>>
>> Something like that ?
>>
>> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
>> index a154ffe6b2..c465eb12e2 100644
>> --- a/xen/arch/x86/Makefile
>> +++ b/xen/arch/x86/Makefile
>> @@ -236,7 +236,9 @@ ifeq ($(CONFIG_DEBUG_INFO),y)
>>         $(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) \
>>                 -O elf64-x86-64 $(TARGET)-syms.efi $@.elf
>>  endif
>> -       $(STRIP) $(TARGET)-syms.efi -o $@
>> +       $(STRIP) $(TARGET)-syms.efi -o $@ || { \
>> +               LANG=C strip $(TARGET)-syms.efi -o $@ 2>&1 | grep -q \
>> +               "relocation count is negative" && mv -f $(TARGET)-syms.efi 
>> $@; }
>>  ifneq ($(CONFIG_DEBUG_INFO),y)
>>         rm -f $(TARGET)-syms.efi
>>  endif
> On Ubuntu 20.04 it fails different way:
>
>     strip: xen.efi: Data Directory size (1c) exceeds space left in section 
> (18)
>     strip: xen.efi: error copying private BFD data: file in wrong format
>
> Looks similar to:
> https://lore.kernel.org/all/3TMd7J2u5gCA8ouIG_Xfcw7s5JKMG06XsDIesEB3Fi9htUJ43Lfl057wXohlpCHcszqoCmicpIlneEDO26ZqT8QfC2Y39VxBuqD3nS1j5Q4=@trmm.net/
>
> Qubes has this patch:
> https://github.com/QubesOS/qubes-vmm-xen/blob/main/0608-Fix-buildid-alignment.patch
>
>     diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
>     index 9a1dfe1b340a..26a23a7b0651 100644
>     --- a/xen/arch/x86/xen.lds.S
>     +++ b/xen/arch/x86/xen.lds.S
>     @@ -171,6 +171,7 @@ SECTIONS
>             __note_gnu_build_id_end = .;
>        } PHDR(note) PHDR(text)
>      #elif defined(BUILD_ID_EFI)
>     +  . = ALIGN(32);
>        DECL_SECTION(.buildid) {
>             __note_gnu_build_id_start = .;
>             *(.buildid)
>
> Lets see if that helps:
> https://gitlab.com/xen-project/people/marmarek/xen/-/pipelines/2167783980

That seems to have fixed 20.04 and 18.04.

The extra line wants a comment at least identifying roughly which
binutils it's a workaround for, so we can drop it eventually.

And, as it's already in a downstream, it should be upstreamed and
backported.

>
> And few lines earlier there is also:
>
>     ld: xen-syms.efi: warning: section .init: alignment 2**15 not 
> representable

This can't be helped.  It's not an error, but you also cant get LD to
shut up about it.

>
>> It will fall back to not stripping in case that bug is detected. I
>> don't know how to test it.
>> (the LANG=C is to always force the English message).
> If going this way, use LC_ALL=C (otherwise LC_ALL=something present in
> the env would override your LANG=C). But given there are different
> messages, this may not be the best option.
>
> And TBH, I don't like silent behavior change based on (unknown) version
> of binutils. Lets see if the alignment adjustment helps. While it
> shouldn't be necessary on newer binutils (thanks to Jan's fix there -
> see thread linked above), IMO it isn't too bad to add it, to keep older
> versions happy. And it can be dropped, once we raise toolchain base
> version next time.

Given it's now only 16.04 broken, how about simply excluding xen.efi
with these broken toolchains?

~Andrew