From: Frediano Ziglio <frediano.ziglio@cloud.com>

Older binutils versions do not handle correctly PE files.
It looks like they could work if they don't produce debug information
but they mess the PE file in other way like putting invalid
flags in sections.
For instance they set IMAGE_SCN_LNK_NRELOC_OVFL flag which should be
set only if the number of relocations are more than 64K and not on
executable (while xen.efi is an executable).
Although some UEFI implementation do not check for these minor flags
we should not allow building not working artifacts.
Also different tools will complain about the format (like
objdump and strip).

Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
Changes since v9:
- explain one of the broken flags.
---
 xen/arch/x86/arch.mk | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/xen/arch/x86/arch.mk b/xen/arch/x86/arch.mk
index 16368a498b..10eb8e4292 100644
--- a/xen/arch/x86/arch.mk
+++ b/xen/arch/x86/arch.mk
@@ -88,13 +88,6 @@ EFI_LDFLAGS := $(patsubst -m%,-mi386pep,$(LDFLAGS)) --subsystem=10 --enable-long
 LD_PE_check_cmd = $(call ld-option,$(EFI_LDFLAGS) --image-base=0x100000000 -o $(efi-check).efi $(efi-check).o)
 XEN_BUILD_PE := $(LD_PE_check_cmd)
 
-# If the above failed, it may be merely because of the linker not dealing well
-# with debug info. Try again with stripping it.
-ifeq ($(CONFIG_DEBUG_INFO)-$(XEN_BUILD_PE),y-n)
-EFI_LDFLAGS += --strip-debug
-XEN_BUILD_PE := $(LD_PE_check_cmd)
-endif
-
 ifeq ($(XEN_BUILD_PE),y)
 
 # Check if the linker produces fixups in PE by default
-- 
2.43.0

On 08.12.2025 14:39, Frediano Ziglio wrote:
> From: Frediano Ziglio <frediano.ziglio@cloud.com>
> 
> Older binutils versions do not handle correctly PE files.
> It looks like they could work if they don't produce debug information
> but they mess the PE file in other way like putting invalid
> flags in sections.
> For instance they set IMAGE_SCN_LNK_NRELOC_OVFL flag which should be
> set only if the number of relocations are more than 64K and not on
> executable (while xen.efi is an executable).
> Although some UEFI implementation do not check for these minor flags
> we should not allow building not working artifacts.

The sentence is self-contradictory imo: When "some UEFI implementation
do not check", what "not working artifacts" are you talking about?

> Also different tools will complain about the format (like
> objdump and strip).
> 
> Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

As said in reply to v9 - I don't think we should be taking this step
unless we can prove the generated binaries to be entirely unusable.
Which, again as said, contradicts my personal experience.

Jan

On Mon, 8 Dec 2025 at 13:56, Jan Beulich <jbeulich@suse.com> wrote:
>
> On 08.12.2025 14:39, Frediano Ziglio wrote:
> > From: Frediano Ziglio <frediano.ziglio@cloud.com>
> >
> > Older binutils versions do not handle correctly PE files.
> > It looks like they could work if they don't produce debug information
> > but they mess the PE file in other way like putting invalid
> > flags in sections.
> > For instance they set IMAGE_SCN_LNK_NRELOC_OVFL flag which should be
> > set only if the number of relocations are more than 64K and not on
> > executable (while xen.efi is an executable).
> > Although some UEFI implementation do not check for these minor flags
> > we should not allow building not working artifacts.
>
> The sentence is self-contradictory imo: When "some UEFI implementation
> do not check", what "not working artifacts" are you talking about?
>

I cannot see the contradiction, some work, some not.

> > Also different tools will complain about the format (like
> > objdump and strip).
> >
> > Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
> > Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
>
> As said in reply to v9 - I don't think we should be taking this step
> unless we can prove the generated binaries to be entirely unusable.

I prefer if the build produces 100% working instead of a russian roulette.

> Which, again as said, contradicts my personal experience.
>

I never said they never work. But implementations keep progressing and
there will be more of them improving their checks. For instance
currently implementations with enhanced memory protection will cause
early crashes.

> Jan

Frediano