similar to: [PATCH] Fix for crash with certain EFIs

Thank you all. It looks like -mno-red-zone flag is already in master branch since commit 7d70885d, but it seems it is applied to all EFI builds. IIUC, the problem only affects efi64 builds. So here's the modification of my patch to only apply -mno-red-zone flag to efi64 target. The patch is against master. I verified that it builds correctly in master. Please feel free to accept or reject

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 both 32-bit. BTW. I also tried 6.04-pre1 and

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,

This patch adds to Com32 modules the capabilities of accessing the EFI environment The idea is simple, the EFI parameters "image" and "table" received by syslinux.efi's efi_main() are stored in the "firmware" structure, next they are retrieved from the Com32 module which is linked against the gnu-efi static library. The Com32 module can use the EFI

Thank you very much for this, I have been running into this issue a number of times but could never get a firm grip on it. Especially HP Gen9 proliants seem to suffer from it by sometimes throwing a stack dump very early in the boot. In the past we worked around it by forcing bios boot. After rebuilding it with -mno-red-zone the problem appears to be fixed, at least after a couple of hours of

On Mon, Sep 14, 2015 at 05:50:58AM +0200, celelibi--- via Syslinux wrote: > index a705440..5ef6702 100644 > --- a/mk/efi.mk > +++ b/mk/efi.mk > @@ -10,6 +10,7 @@ core = $(topdir)/core > GCCOPT := $(call gcc_ok,-fno-stack-protector,) > EFIINC = $(objdir)/include/efi > LIBDIR = $(objdir)/lib > +EFIDIR = $(topdir)/gnu-efi/gnu-efi-3.0 Would it make sense to add AROPT =

More recent versions of the GNU linker (>= 2.31) create a separate code "PT_LOAD" segment by default (as of https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=f6aec96dce1ddbd8961a3aa8a2925db2021719bb). Building syslinux EFI images with this -zseparate-code enabled creates broken EFI images, since efi/wrapper.c only copies the first PT_LOAD segment to the EFI. This patch adds

I tend to use the same tool-chain across various hosts so I made this very simple patch that allows you to pass the cross-compiler name to make ( e.g. make CROSS_COMPILE=i686-nptl-linux-gnu-). I'm not sure if patches should be attached or just pasted inline so I did both this time. BTW, it's relative to syslinux 4 but the same changes work with syslinux 3 although the patch won't

From: Matt Fleming <matt.fleming at linux.intel.com> Move the MCONFIG files into a mk/ directory and give them more descriptive names. This is purely a cosmetic change to make the 'include' directives a bit more coherent by making it obvious exactly which MCONFIG file we're including. For example, in com32/lua/src/Makefile we exchange the line, include ../../MCONFIG for the

From: Sylvain Gault <sylvain.gault at gmail.com> The error-prone shell scripts for building gnu-efi are replaced by a Makefile recipe. This is accompanied with a small update of gnu-efi which, despite not strongly mandatory, avoid recompiling gnu-efi and all the efi subtree on each invocation of make. Signed-off-by: Sylvain Gault <sylvain.gault at gmail.com> ---

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

When we add -ffreestanding the compiler won't get to inline this any more. Signed-off-by: David Woodhouse <dwmw2 at infradead.org> --- com32/lib/math/fabs.S | 15 +++++++++++++++ mk/lib.mk | 2 +- 2 files changed, 16 insertions(+), 1 deletion(-) create mode 100644 com32/lib/math/fabs.S diff --git a/com32/lib/math/fabs.S b/com32/lib/math/fabs.S new file mode 100644 index

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

From: Matt Fleming <matt.fleming at linux.intel.com> This series includes a patch (PATCH 1/6) that I sent previously but I thought it was worth sending it again since the rest of the series depends on it, and it also gives a bit of context. These cleanups make it simpler to do the big switchover to ELF modules on the elflink branch because the libraries in $LIBS are now contained in one

From: Sylvain Gault <sylvain.gault at gmail.com> These few patches contain a few improvement about the Makefiles for EFI. Mainly, to rebuild the files when needed, and only when needed. The three shell scripts efi/{check,build,clean}-gnu-efi.sh disappeared and are now integrated as makefile recipes. You'll notice an argument ARFLAGS=rvU to the recursive make calls to gnu-efi. This is

Hi, I don't know whether parallel make compatibility is sth you care for, but I feel like the gcc_ok target may ruin it. And that would be easy to fix by reintroducing the mktemp call like for example gcc_ok = $(shell tmpf=$$(mktemp -t gcc_ok.XXXXXX); \ [...] It just occured to me. -- Thanks, Feri.

1) mk/syslinux.mk runs a shell to make a temp file gcc_ok.$$$$.tmp (perhaps in the wrong directory) while several Makefiles have an include rule for *.tmp which I believe is causing some occasional parallel build issues. make[3]: Entering directory `/home/gene/s/g/bios/memdump' gcc_ok.6333.tmp:1: warning: NUL character seen; rest of line ignored gcc_ok.6333.tmp:1: *** missing separator.

>>> > 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 other similar parameters probably overlooked on EFI

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

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