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

Celelibi celelibi at gmail.com
Sat Nov 28 08:59:29 PST 2015


2015-11-28 8:47 UTC+01:00, Ady via Syslinux <syslinux at zytor.com>:
>
>> From: Sylvain Gault <sylvain.gault at gmail.com>
>>
>> The System V ABI for x86-64 specify that a "red zone" is an area of 128
>> bytes
>> above the current stack frame. This area can be used by a called function
>> in
>> order to avoid the overhead of modifying the stack pointer. The direct
>> effect
>> is that interrupt/event/signal handlers must not write to this area. In
>> the
>> UEFI calling convention, there is no such thing and the event handlers do
>> write
>> their data just above the current stack frame.
>>
>> However, gcc generate by default code that uses the red zone. This has to
>> be
>> disabled explicitely with the option -mno-red-zone. Not doing so lead to
>> some
>> functions behaving randomly once in a while.
>>
>> Fixing this revealed that some Makefiles out of the efi/ directory have
>> some
>> specific options when building for BIOS or for EFI. These Makefiles do
>> this by
>> testing the EFI_BUILD variable. However, this variable wasn't passed down
>> the
>> Makefiles making these specific options never used.
>>
>
> The addition of the EFI_BUILD variable inside Makefiles could potentially
> affect scripts such as package builders, perhaps even the way the
> official (pre)release archives are built(?).

This variable is not something you're supposed to see or use when
building Syslinux.

I kinda have the feeling that according to you, no commit shall ever
be made again because it may have an interaction with the user /
maintainer.

Maybe some users rely on the presence of the bugs. Who knows? The
difference between a bug and a feature is pretty subjective after all.

>
> For further details and explanation, see the commit "The make files have
> undergone changes to support both i386 and x86_64 platforms" (2012Jun):
>  repo.or.cz/syslinux.git/commit/38e58635d3868c23537fc5dce87b152a52df34ad
>
> Perhaps we should consider how to improve the Makefiles without
> potentially breaking backwards compatibility?

The way I think the Makefiles could be improved is by rewriting them
from scratch in a non-recursive way.

> PS: Shouldn't this type of things (as described in the aforementioned
> commit from 2012Jun) be included in "./doc/building.txt" and in the
> corresponding wiki page?

Why should they?


Celelibi


More information about the Syslinux mailing list