[syslinux] [PATCH 0/2] Do not use the "red zone" on EFI

Patrick Masotta masottaus at yahoo.com
Tue Dec 1 04:15:19 PST 2015

Your mail in in HTML. :)<<<
I just use the Yahoo editor; Sorry I'll try to see how to force the text mode.

I checked the whole log. The only lines in the logs of "make efi64"
starting with gcc that do not contain -mno-red-zone are:
- linking invocations
- used to compiles .lo files that produce fancyhello.lnx and
keytest.lnx (what are those?)
- used to build tools that only run on the compiling host: relocs,
prepcore, wrapper (note that relocs is no longer used at all)
- used to compile assembly file which obviously control the stack usage.

The very same goes for "make efi32". "Make bios" produce no occurrence
of -mno-red-zone.

Regarding the other flags needed, I'll take those from this link:

- -fno-stack-protector has the same exceptions as above + the
installers (which is the right thing to do).
- -fPIC is used instead of -fpic, which is good. However, this option
is not always specified for efi32, by looking at mk/embedded.mk, it
seems to be on purpose. I wonder about the implications of this.
syslinux.efi is however always linked with -pie which should be enough
to work.
- -fshort-wchar is missing out of the efi/ directory. The only places
where wchar_t is used are in the directories lzo and gpxe, same for
litteral strings with L prefix. We should probably enable this option
all the time given it would have no actual effect currently.
- -DEFI_FUNCTION_WRAPPER is still defined in some places but never
used at all. It shall be replaced by GNU_EFI_USE_MS_ABI under some

So unless there is an objection I may send a patch for those options
although it should be a no-op.

Best regards,


Your list looks good, we should probably also take a look to other projects like 
Grub, iPXE, etc and see what they use.
I agree with you the wrong use of something like i.e. the "red-zone" can lead to 
"very" hard to trace erratic bugs.

But I also understand Ady's concerns; this mod touches the inner of  the whole 
building process; we must move carefully here.

I appreciate your efforts on this issue. 



More information about the Syslinux mailing list