Syslinux - Nov 2015 - [PATCH 0/2] Do not use the "red zone" on EFI

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

> 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
>

On Sat, Nov 28, 2015 at 8:58 PM, Ady via Syslinux <syslinux at zytor.com>
wrote:
> I'm not sure I understand what you are saying.
I don't think you understand the current build system.  How many times
have you built Syslinux from just source?
> Why exactly the following quote from the referenced commit is not
> relevant / adequate for "doc/building.txt" and/or for the
corresponding
> wiki page?
Incorrect use.
> [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?
Yes and Yes
> Would that usage of "make" fail?
I'd be completely surprised if a working object ever comes out of that
unless aligned.
> 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?
The firmwares FORCIBLY set these.  See 1408e6ca
> 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?
To my knowledge, "make" with some special sauce that just marks the
binary with proper versioning.
> I would like to extend such questions to package maintainers, but I
> doubt anyone would answer.
-- 
-Gene