search for: mregparm

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Was just working with the latest 3.54, and find that the Makefile in the menu directory didn't work until I added the /include/syslinux to the file. < CFLAGS = $(M32) -mregparm=3 -DREGPARM=3 -W -Wall - march=i386 -Os -fomit-frame-pointer -I$(LUDIR)/include - I$(COM32DIR)/include -I$(COM32DIR)/include/syslinux -Ilibmenu - D__COM32__ - --- > CFLAGS = $(M32) -mregparm=3 -DREGPARM=3 -W -Wall - march=i386 -Os -fomit-frame-pointer -I$(LUDIR)/include - I$(COM32DIR)/inclu...

I think I see what's going on, and I agree it looks like a bug. It was too much to hope that later passes weren't going to mess with the PUSH instruction. :( While I was trying to reproduce your problem, I think I found another one that looks like this: $ clang -S -O2 -m32 -mregparm=3 -mretpoline spill_across_rp.cpp -o - | grep _retpoline_push -B2 ... movl %eax, 8(%esp) # 4-byte Spill ... pushl %edi movl 8(%esp), %edi # 4-byte Reload calll __llvm_retpoline_push That's obviously broken, it doesn't account fo...

...arranged it this way because the x86 call instruction puts the > intended return address on the top of the stack, and there's no easy > way to put it anywhere else. We use this thunk when we want to make > an indirect call and there are no available scratch registers, i.e. > 32-bit -mregparm=3 and the call has three or more arguments, which > happens in Linux. One way to avoid this would be to compile with > -mregparm=2, but that would pessimize direct calls unnecessarily. > > It sounds like Linux is already providing its own thunks, so it might > be better to for us to...

...undary=8,) #GCCOPT += $(call gcc_ok,-incoming-stack-boundary=8,) @@ -48,9 +51,7 @@ GCCOPT += $(call gcc_ok,-falign-labels=0,-malign-labels=0) GCCOPT += $(call gcc_ok,-falign-loops=0,-malign-loops=0) -ifeq ($(FWCLASS),EFI) -GCCOPT += -mno-red-zone -else +ifneq ($(FWCLASS),EFI) GCCOPT += -mregparm=3 -DREGPARM=3 endif --- syslinux.orig/mk/efi.mk +++ syslinux/mk/efi.mk @@ -17,6 +17,7 @@ endif ifeq ($(ARCH),x86_64) ARCHOPT = -m64 -march=x86-64 + ARCHOPT += -mno-red-zone EFI_SUBARCH = $(ARCH) endif @@ -29,7 +32,7 @@ -I$(core)/include -I$(core)/ $(ARCHO...

...op of the stack. I arranged it this way because the x86 call instruction puts the intended return address on the top of the stack, and there's no easy way to put it anywhere else. We use this thunk when we want to make an indirect call and there are no available scratch registers, i.e. 32-bit -mregparm=3 and the call has three or more arguments, which happens in Linux. One way to avoid this would be to compile with -mregparm=2, but that would pessimize direct calls unnecessarily. It sounds like Linux is already providing its own thunks, so it might be better to for us to go back to the __llvm_re...

...fpregs saved even though klibc doesn't do fp? >For gcc targetting Aarch64, We can only guarantee that d8-d15 are >left alone when -mgeneral-regs-only is supplied for building klibc >and any software linked against klibc. I would much prefer to We can enforce this in klcc, just like -mregparm=3 is used by the i386 target. bye, //mirabilos -- ?Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.? -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: ?[?]uhr.gz is a reason to install mksh on every system.?)

...g to compile the version on rhel 5.x box. Nasm version 0.98.39 I extracted the tar.gz and ran make in the extracted directory. Here is where it stops. gcc -Wp,-MT,rawcon.o,-MD,./.rawcon.o.d -m32 -ffreestanding -fno-stack-protector -fwrapv -freg-struct-return -march=i386 -Os -fomit-frame-pointer -mregparm=3 -DREGPARM=3 -msoft-float -fno-exceptions -fno-asynchronous-unwind-tables -fno-strict-aliasing -falign-functions=0 -falign-jumps=0 -falign-labels=0 -falign-loops=0 -mpreferred-stack-boundary=2 -mincoming-stack-boundary=2 -fvisibility=hidden -g -W -Wall -Wstrict-prototypes -Wno-sign-compare -I./inc...

I have, hopefully, found and fixed the issue with non-kernel binaries that appeared in 3.35. As a result, I have pushed out 3.36-pre6 and am classifying it as a release candidate. Please try it out, especially if you have had problems with 3.35. ftp://ftp.kernel.org/pub/linux/utils/boot/syslinux/Testing/ -hpa

...r program for doing this? like uclibc did with their earlier versions. I looked at the make process and did a bit reading and figure out this much: gcc -Wp,[preprocessor options] -MT,[target_name_I_think] tests/hello.o, -MD,[include dependency] tests/.hello.o.d -mregparm=3 -DREGPARM=3 [Control how many registers are used to pass integer arguments] -march=i386 [arch] -Os [optimization] -g [debug info] -falign-functions=0 -falign-jumps=0 -falign-loops=0 [I think they are to optimize for size] -nostdinc -iwithprefix [include dir prefix] include -D__KLIB...

...'s going on, and I agree it looks like a bug. It was too > much to hope that later passes weren't going to mess with the PUSH > instruction. :( > > While I was trying to reproduce your problem, I think I found another one > that looks like this: > > $ clang -S -O2 -m32 -mregparm=3 -mretpoline spill_across_rp.cpp -o - | grep > _retpoline_push -B2 > ... > movl %eax, 8(%esp) # 4-byte Spill > ... > pushl %edi > movl 8(%esp), %edi # 4-byte Reload > calll __llvm_retpoline_push > > That's...

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,

Got the following trying to build git master: gcc -std=gnu99 -m32 -fno-stack-protector -mregparm=3 -DREGPARM=3 -march=i386 -Os -W -Wall -march=i386 -fomit-frame-pointer -D__COM32__ -nostdinc -iwithprefix include -I../../com32/libutil/include -I../../com32/include -c -o chain.o chain.c ld -m elf_i386 -T ../../com32/lib/com32.ld -o chain.elf chain.o ../../com32/libutil/libutil_com.a ../../com3...

Hi! I have just tried to build menu.c32 but it fails. 3.20pre3 works fine though. Here is what happens: bash-3.1$ make gcc -m32 -mregparm=3 -DREGPARM=3 -W -Wall -march=i386 -Os -fomit-frame-pointer -I../libutil/include -I../include -D__COM32__ -c -o menu.o menu.c menu.c: In function `run_menu': menu.c:549: warning: variable `done' might be clobbered by `longjmp' or `vfork' menu.c:551: warning: variable `top' m...

make[1]: Entering directory `/syslinux-4.02-6-ge841d69/dos' gcc -Wp,-MT,syslxopt.o,-MD,./.syslxopt.o.d -m32 -ffreestanding -fno-stack-protector -fwrapv -freg-struct-return -march=i386 -Os -fomit-frame-pointer -mregparm=3 -DREGPARM=3 -msoft-float -fno-exceptions -fno-asynchronous-unwind-tables -fno-strict-aliasing -falign-functions=0 -falign-jumps=0 -falign-labels=0 -falign-loops=0 -mpreferred-stack-boundary=2 -mincoming-stack-boundary=2 -g -W -Wall -Wstrict-prototypes -Wno-clobbered -Werror -Wno-sign-compare...

...s, since the following patch fixes the problem for me: --- klibc/arch/i386/MCONFIG~ 2004-02-21 17:49:26.000000000 -0500 +++ klibc/arch/i386/MCONFIG 2004-02-22 17:59:58.000000000 -0500 @@ -9,7 +9,7 @@ # Enable this to compile with register parameters; only safe for # gcc > 3 -REGPARM_OPT := -mregparm=3 -DREGPARM +#REGPARM_OPT := -mregparm=3 -DREGPARM gcc_major := $(shell $(CC) -v 2>&1 | awk '/gcc version/{print int($$3)}') This is a real downer when using klibc+ash for /linuxrc :-). My GCC identifies itself as "gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)"...

...does not function properly. Testcase: read cmdline </proc/cmdline echo $cmdline The first command prints a message: cannot open /proc/cmdline: error 14 Other shell redirections don't work either. When I comment out the following line in klibc/klibc/arch/i386/MCONFIG: # REGPARM_OPT := -mregparm=3 -DREGPARM and rebuild klibc, everything works. Please take some action against this error, e.g. update the README file. -- Alexander E. Patrakov

--- ../multipath-tools-0.2.8.1/klibc/klibc/arch/i386/MCONFIG 2004-07-20 10:51:42.000000000 +0200 +++ klibc/klibc/arch/i386/MCONFIG 2004-07-27 17:10:12.000000000 +0200 @@ -13,7 +13,7 @@ # them to be cdecl # REGPARM = -mregparm=3 -DREGPARM -gcc_major := $(shell $(CC) -v 2>&1 | awk '/gcc version/{print int($$3)}') +gcc_major := $(shell unset LANG;$(CC) -v 2>&1 | awk '/gcc version/{print int($$3)}') OPTFLAGS = $(REGPARM) -march=i386 -Os --

I get this with current linus bk now and klibc 187 [jonsmirl@smirl ash]$ make sh mknodes.sh nodetypes nodes.c.pat . gcc -Wp,-MD,.cd.d -mregparm=3 -DREGPARM=3 -march=i386 -Os -g -falign-functions=0 -falign-jumps=0 -falign-loops=0 -nostdinc -iwithprefix include -D__KLIBC__ -DBITSIZE=32 -I../include/arch/i386 -I../include/bits32 -I../include -I../linux/include -I../linux/include2 -I../linux/include -DSHELL -DJOBS=0 -I. -c -o cd.o cd.c gcc...

...inux/autoconf.h -D__KERNEL__ -Iinclude -I/home/sclark/rpmbuild/BUILD/kernel-2.6.32/arch/x86/include -include include/linux/autoconf.h -g -Os -D_SETUP -D_WAKEUP -D__KERNEL__ -I/home/sclark/rpmbuild/BUILD/kernel-2.6.32/arch/x86/kernel/acpi/realmode/../../../boot -Wall -Wstrict-prototypes -march=i386 -mregparm=3 -include /home/sclark/rpmbuild/BUILD/kernel-2.6.32/arch/x86/kernel/acpi/realmode/../../../boot/code16gcc.h -fno-strict-aliasing -fomit-frame-pointer -ffreestanding -fno-toplevel-reorder -fno-stack-protector -mpreferred-stack-boundary=2 -m32 -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME...