search for: efi_build

...s 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. Best regards, Sylvain Gault Sylvain Gault (2): Makefile: Pass down the variable EFI_BUILD Makefile: Always use -mno-red-zone for EFI Makefile | 17 +++++++++-------- com32/M...

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

...hy 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 "m...

...e > > > 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 &...

...upported by the Windows ABI. Without this, syslinux crashes on some UEFI implementations. --- syslinux-6.03-orig/mk/com32.mk +++ syslinux-6.03/mk/com32.mk @@ -29,6 +29,9 @@ ifeq ($(strip $(ARCH)),x86_64) GCCOPT += $(call gcc_ok,-m64,) GCCOPT += $(call gcc_ok,-march=x86-64) +ifdef EFI_BUILD + GCCOPT += $(call gcc_ok,-mno-red-zone) +endif #let the stack-boundary default to whatever it is on 64bit #GCCOPT += $(call gcc_ok,-mpreferred-stack-boundary=8,) #GCCOPT += $(call gcc_ok,-incoming-stack-boundary=8,) --- syslinux-6.03-orig/mk/efi.mk +++ syslinux-6.03/m...

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

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

Hi Ady, Would it work if we removed "ifdef EFI_BUILD" condition and just add -mno-red-zone for all x86_64 builds? If not, do you have any ideas how to pass this flag? This could work, because the patch is adding the -mno-red-zone flag only for x86_64 builds, which are only used in the form of the efi64 target. The efi32 and bios targets are bot...

...enable debugging under EFI? Normal printf output remains invisible, so DEBUG_STDIO doesn't work. If there is nothing yet, I think a wrapper around printf (and *prinf) is needed. This should [v]sprintf() to a buffer and then print the resulting buffer using APrint("%a", buffer) if EFI_BUILD is defined.

...ely 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 a...

>>> > 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(?). <<< I think the -mno-red-zone thing is a good catch, the rest of EFI projects all use it; now I wonder if there might be ot...

...th -mno-red-zone the problem appears to be fixed, at least after a couple of hours of testing I have not seen it anymore. One comment: --- syslinux-6.03-orig/mk/efi.mk +++ syslinux-6.03/mk/efi.mk @@ -17,6 +17,9 @@ endif ifeq ($(ARCH),x86_64) ARCHOPT = -m64 -march=x86-64 +ifdef EFI_BUILD + ARCHOPT = -mno-red-zone +endif I would do this (add a plus): ARCHOPT += -mno-red-zone Thanks, Jur van der Burg.

2015-11-30 14:14 UTC+01:00, Patrick Masotta <masottaus at yahoo.com>: >>>> >> 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(?). > <<< > > I think the -mno-red-zone thing is a good catch, the rest of EFI projects > all use it; > no...

On 05-08-15 12:05, Gene Cumm wrote: > > I recompiled with this in mk/devel.mk <http://devel.mk>: > > GCCWARN += -DDEBUG_PORT=0x2f8 -DCORE_DEBUG=1 > > 0x2f8 is a BIOSism. Is this a problem? The example in the comments said 0x3f8 which is COM1.

...y some firmware engineers have this problem too. ;-) >>>> > If there is nothing yet, I think a wrapper around printf > (and *prinf) is > needed. This should [v]sprintf() to a buffer and then print the > resulting buffer using APrint("%a", buffer) if EFI_BUILD is > defined. > <<< > It sounds logical. Even Print("%a", buf) would work. I first used APrint() because the format string for it is a const char *, whereas Print() expects a const unsigned short * pointing to an unicode string. But then I found that any %s in b...

...tely 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. > > Best regards, > Sylvain Gault Almost done with a round of testing and I hope to push the patch tonight or tomorrow. --Gene

...gned-off-by: Matt Fleming <matt.fleming at intel.com> --- Makefile | 2 +- efi/Makefile | 2 -- 2 files changed, 1 insertion(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 3861168..9c886d8 100644 --- a/Makefile +++ b/Makefile @@ -164,7 +164,7 @@ BOBJECTS = $(BTARGET) \ ifdef EFI_BUILD BSUBDIRS = codepage com32 lzo core mbr sample efi txt -ISUBDIRS = efi utils +ISUBDIRS = INSTALLSUBDIRS = efi diff --git a/efi/Makefile b/efi/Makefile index 2003430..c89ca06 100644 --- a/efi/Makefile +++ b/efi/Makefile @@ -66,8 +66,6 @@ codepage.o: ../codepage/cp865.cp cp $(objdir)/../code...

On Sat, 22 Jun, at 05:24:21PM, Ferenc Wagner wrote: > Matt Fleming <matt at console-pimps.org> writes: > > > Please do test out the release and report any regressions. > > Unfortunately, I can't make it under Debian wheezy + experimental > gnu-efi (ie. 3.0u+debian-1): > > $ make installer [...] > make[3]: *** No rule to make target

>>> > On 05-08-15 12:05, Gene Cumm wrote: >> >>? > I recompiled with this in mk/devel.mk <http://devel.mk>: >>? >? GCCWARN += -DDEBUG_PORT=0x2f8 -DCORE_DEBUG=1 >> >> 0x2f8 is a BIOSism. > Is this a problem? The example in the comments said 0x3f8 which is COM1. It means that a BIOS IO port for a UART won't work for EFI.? No

.../pxe/pxe.c | 5 +++++ core/fs/pxe/pxe.h | 12 ++++++++++++ doc/pxelinux.txt | 21 +++++++++++++++++---- 4 files changed, 35 insertions(+), 4 deletions(-) diff --git a/core/Makefile b/core/Makefile index a7503ef..233a374 100644 --- a/core/Makefile +++ b/core/Makefile @@ -82,6 +82,7 @@ ifdef EFI_BUILD FILTER_OBJS += $(subst $(SRC)/,, \ $(patsubst %.c,%.o, $(wildcard $(SRC)/thread/*.c)) \ $(patsubst %.S,%.o, $(wildcard $(SRC)/thread/*.S))) +CFLAGS += -D__EFI__ endif COBJS = $(filter-out $(FILTER_OBJS),$(COBJ)) diff --git a/core/fs/pxe/pxe.c b/core/fs/pxe/pxe.c index 4de4dbf..5cc9082 100...