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

Ady ady-sf at hotmail.com
Sat Nov 28 17:58:46 PST 2015


> On Nov 28, 2015 2:51 AM, "Ady via Syslinux" <syslinux at zytor.com> wrote:
> 
> > > 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(?).
> 
> Feels like a merge/design oversight.
> 
> > 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
> 
> This looks superseded by the current design that can simultaneously build
> all three architectures at once.
> 
> > Perhaps we should consider how to improve the Makefiles without
> > potentially breaking backwards compatibility?
> >
> > Regards,
> > Ady.
> >
> > 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?
> 
> See above.
> 
> --Gene
 
I'm not sure I understand what you are saying.

Why exactly the following quote from the referenced commit is not 
relevant / adequate for "doc/building.txt" and/or for the corresponding 
wiki page?

[quote]
On a x86_64 platform, the following cross-builds syslinux for i386
 To build for i386: make EFI_BUILD=1 ARCH=i386
 
On a x86_64 platform, the following builds syslinux for x86_64
 To build natively: make EFI_BUILD=1
[/quote]

Aren't 'ARCH' and 'EFI_BUILD' still there? Aren't they valid / 
relevant?

Would that usage of "make" fail?

Does the 'make "firmware"' usage contradict / supersede / cancel in any 
way the 'ARCH' and/or 'EFI_BUILD' options? Can't all these commands / 
options live together?

If the suggested patch were to be merged, would such usage of "make" be 
affected?

A question for Peter: how is 'make' executed, regarding the above 
options, so to build the current official versions of Syslinux?

I would like to extend such questions to package maintainers, but I 
doubt anyone would answer.

Regards,
Ady. 
 
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> 




More information about the Syslinux mailing list