[syslinux] [PATCH] mk/efi: add -znoseparate-code to LD_FLAGS for EFI builds

[Ady]

> More recent versions of the GNU linker (>= 2.31) create a separate
> code "PT_LOAD" segment by default (as of
> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=f6aec96dce1ddb
> d8961a3aa8a2925db2021719bb). Building syslinux EFI images with this
> -zseparate-code enabled creates broken EFI images, since efi/wrapper.c
> only copies the first PT_LOAD segment to the EFI. This patch adds
> -znoseparate-code to the LD_FLAGS for EFI builds to restore the original
> behavior.
> 
> PS: I am aware that development activity is low. We still wanted to
> contribute this fix in case it may be helpful to anyone.
> 
> Thanks
> Johannes
> 
> Signed-off-by: Johannes Frohnhofen <jf at daedalean.ai>
> 
> --- mk/efi.mk.orig 2020-07-28 12:31:48.814356659 +0000
> +++ mk/efi.mk 2020-07-28 12:37:22.292205578 +0000
> @@ -37,7 +37,8 @@ CRT0 := $(LIBDIR)/crt0-efi-$(EFI_SUBARCH
>  LDSCRIPT := $(LIBDIR)/elf_$(EFI_SUBARCH)_efi.lds
> 
>  LDFLAGS = -T $(SRC)/$(ARCH)/syslinux.ld -Bsymbolic -pie -nostdlib
> -znocombreloc \
> - -L$(LIBDIR) --hash-style=gnu -m elf_$(ARCH) $(CRT0) -E
> + -znoseparate-code -L$(LIBDIR) --hash-style=gnu -m elf_$(ARCH) \
> +                $(CRT0) -E
> 
>  SFLAGS     = $(GCCOPT) $(GCCWARN) $(ARCHOPT) \
>        -fomit-frame-pointer -D__COM32__ -D__FIRMWARE_$(FIRMWARE)__ \
 
 
Thank you.

FWIW...

The problem of multiple "PT_LOAD" segments as of binutils 2.31+ is 
already mentioned (among others) at: 
 syslinux.org/wiki/index.php/Building 

The patch used by Debian is different than the patch being proposed now 
here.

Debian's patch: 
 
salsa.debian.org/images-team/syslinux/commit/012e1dd312eb8c1f9a52239966e
0be0169d7af98 

was/were sent upstream to this Syslinux mailing list almost 2 years 
ago:

A. www.syslinux.org/archives/2018-August/026167.html 
 fix syslinux.efi (Re: Unable to get syslinux.efi to work, grub2 boots 
tho) 

B. www.syslinux.org/archives/2018-August/026168.html 
 Discard .note.gnu.property section to fix build failure 

IIRC, those (by-now-two-years-old) proposed patches were ignored here, 
yet they are being used by several Linux distributions in their 
respective Syslinux-related packages.

I don't know whether this new proposal would have an equivalent result 
to either: 

* Aforementioned "A." or to; 
* Aforementioned "B." or to; 
* "A. and B." combined.

Regards,
Ady.