-fomit-frame-pointer makes seabios fail with v2. I'd like to understand the reason why we want it enabled and how we can fix it.
Thanks, Myles
from gcc:
-fomit-frame-pointer Don’t keep the frame pointer in a register for functions that don’t need one. This avoids the instructions to save, set up and restore frame pointers; it also makes an extra register available in many functions. It also makes debugging impossible on some machines.
On some machines, such as the VAX, this flag has no effect, because the standard calling sequence automatically handles the frame pointer and nothing is saved by pretending it doesn’t exist. The machine-description macro "FRAME_POINTER_REQUIRED" controls whether a target machine supports this flag.
Enabled at levels -O, -O2, -O3, -Os.
On Wed, Mar 18, 2009 at 12:41 PM, Myles Watson mylesgw@gmail.com wrote:
-fomit-frame-pointer makes seabios fail with v2. I'd like to understand the reason why we want it enabled and how we can fix it.
gag. It would be nice to make a small. low-complexity payload that fails (just hello, world to serial port might do). Possible?
ron
On Wed, Mar 18, 2009 at 12:48:05PM -0700, ron minnich wrote:
On Wed, Mar 18, 2009 at 12:41 PM, Myles Watson mylesgw@gmail.com wrote:
-fomit-frame-pointer makes seabios fail with v2. I'd like to understand the reason why we want it enabled and how we can fix it.
gag. It would be nice to make a small. low-complexity payload that fails (just hello, world to serial port might do). Possible?
FILO fails too. Maybe we should try coreinfo?
Thanks, Ward.
On Wed, Mar 18, 2009 at 1:50 PM, Ward Vandewege ward@gnu.org wrote:
On Wed, Mar 18, 2009 at 12:48:05PM -0700, ron minnich wrote:
On Wed, Mar 18, 2009 at 12:41 PM, Myles Watson mylesgw@gmail.com wrote:
-fomit-frame-pointer makes seabios fail with v2. I'd like to understand the reason why we want it enabled and how we can fix it.
gag. It would be nice to make a small. low-complexity payload that fails (just hello, world to serial port might do). Possible?
Sure. My bet is that all payloads will fail because we're playing with the way parameters are passed and there's some assembly in jmp_t_elf_entry (src/arch/i386/boot/boot.c) that wasn't told.
FILO fails too. Maybe we should try coreinfo?
I'll try it.
Thanks, Myles
are the payloads built with omit frame pointer?
it's not a good thing if we have to sync how payloads are built with how coreboot is built.
ron
On Wed, Mar 18, 2009 at 01:01:41PM -0700, ron minnich wrote:
are the payloads built with omit frame pointer?
FILO appears to be, cf. line 96 in Makefile:
CFLAGS += -Wall $(STACKPROTECT) $(INCLUDES) -Os -fomit-frame-pointer -fno-common -ffreestanding -fno-strict-aliasing
it's not a good thing if we have to sync how payloads are built with how coreboot is built.
Right!
Thanks, Ward.
would be nice to get this to fail under bochs. You can get a lot of info when things go wrong. You might want to give that a try.
ron
On Wed, Mar 18, 2009 at 2:09 PM, Ward Vandewege ward@gnu.org wrote:
On Wed, Mar 18, 2009 at 01:01:41PM -0700, ron minnich wrote:
are the payloads built with omit frame pointer?
FILO appears to be, cf. line 96 in Makefile:
CFLAGS += -Wall $(STACKPROTECT) $(INCLUDES) -Os -fomit-frame-pointer -fno-common -ffreestanding -fno-strict-aliasing
So matching them breaks it.
it's not a good thing if we have to sync how payloads are built with how coreboot is built.
Right!
I think the breakage is occurring before the payload executes, but I'm not sure of that.
qemu: fatal: Trying to execute code outside RAM or ROM at 0xf10002ba
EAX=0c5a1400 EBX=000f6473 ECX=020078c3 EDX=00000000 ESI=0000b476 EDI=c8000015 EBP=00001001 ESP=00017ffc EIP=f10002ba EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0000 00000000 00000000 00000000 CS =0010 00000000 ffffffff 00cf9b00 SS =0018 00000000 ffffffff 00cf9300 DS =0018 00000000 ffffffff 00cf9300 FS =0018 00000000 ffffffff 00cf9300 GS =0018 00000000 ffffffff 00cf9300 LDT=0000 00000000 0000ffff 00008000 TR =0000 00000000 0000ffff 00008000 GDT= 00000500 00000027 IDT= 0000cd34 0000009f CR0=60000011 CR2=00000000 CR3=00000000 CR4=00000000 CCS=0c5a1400 CCD=0c5a1400 CCO=ADDB FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 Aborted
Thanks, Myles
On Wed, Mar 18, 2009 at 02:17:57PM -0600, Myles Watson wrote:
I think the breakage is occurring before the payload executes, but I'm not sure of that.
qemu: fatal: Trying to execute code outside RAM or ROM at 0xf10002ba
The bug is in src/arch/i386/boot/boot.c. The inline assembly in jmp_to_elf_entry uses the "g" flag to pass in parameters. However, "g" allows gcc to use stack relative addressing of parameters. Unfortunately, the inline assembly modifies %esp - and thus the stack relative values become incorrect.
As a guess, without -fomit-frame-pointer, gcc would pass use %ebp relative values and this wouldn't trigger - but regardless it is still a bug.
-Kevin
On Wed, Mar 18, 2009 at 2:08 PM, Kevin O'Connor kevin@koconnor.net wrote:
The bug is in src/arch/i386/boot/boot.c. The inline assembly in jmp_to_elf_entry uses the "g" flag to pass in parameters. However, "g" allows gcc to use stack relative addressing of parameters. Unfortunately, the inline assembly modifies %esp - and thus the stack relative values become incorrect.
As a guess, without -fomit-frame-pointer, gcc would pass use %ebp relative values and this wouldn't trigger - but regardless it is still a bug.
That's a mighty nice catch. This code has worked unchanged for a long time -- it's amazing how something can just break on you like this.
Thanks
ron
Kevin O'Connor wrote:
On Wed, Mar 18, 2009 at 02:17:57PM -0600, Myles Watson wrote:
I think the breakage is occurring before the payload executes, but I'm not sure of that.
qemu: fatal: Trying to execute code outside RAM or ROM at 0xf10002ba
The bug is in src/arch/i386/boot/boot.c. The inline assembly in jmp_to_elf_entry uses the "g" flag to pass in parameters. However, "g" allows gcc to use stack relative addressing of parameters.
Does it? I could not find that in the GCC Inline Assembly FAQ.
Would changing the parameters to "m" solve the problem?
Stefan
On Thu, Mar 19, 2009 at 01:49:23AM +0100, Stefan Reinauer wrote:
Kevin O'Connor wrote:
On Wed, Mar 18, 2009 at 02:17:57PM -0600, Myles Watson wrote:
I think the breakage is occurring before the payload executes, but I'm not sure of that.
qemu: fatal: Trying to execute code outside RAM or ROM at 0xf10002ba
The bug is in src/arch/i386/boot/boot.c. The inline assembly in jmp_to_elf_entry uses the "g" flag to pass in parameters. However, "g" allows gcc to use stack relative addressing of parameters.
Does it? I could not find that in the GCC Inline Assembly FAQ.
Somewhere it says it can be an offsettable memory address.
Would changing the parameters to "m" solve the problem?
I don't think so. Easiest fix would be to change "g" to "ri" - put the parameter either in a register or as an immediate value.
-Kevin
On Wed, Mar 18, 2009 at 7:55 PM, Kevin O'Connor kevin@koconnor.net wrote:
On Thu, Mar 19, 2009 at 01:49:23AM +0100, Stefan Reinauer wrote:
Kevin O'Connor wrote:
On Wed, Mar 18, 2009 at 02:17:57PM -0600, Myles Watson wrote:
I think the breakage is occurring before the payload executes, but I'm not sure of that.
qemu: fatal: Trying to execute code outside RAM or ROM at 0xf10002ba
The bug is in src/arch/i386/boot/boot.c. The inline assembly in jmp_to_elf_entry uses the "g" flag to pass in parameters. However, "g" allows gcc to use stack relative addressing of parameters.
Does it? I could not find that in the GCC Inline Assembly FAQ.
Somewhere it says it can be an offsettable memory address.
Would changing the parameters to "m" solve the problem?
I don't think so. Easiest fix would be to change "g" to "ri" - put the parameter either in a register or as an immediate value.
That fixes it for me. Patch attached.
Signed-off-by: Myles Watson mylesgw@gmail.com
Thanks, Myles
On 19.03.2009 22:21 Uhr, Myles Watson wrote:
That fixes it for me. Patch attached.
Signed-off-by: Myles Watson mylesgw@gmail.com
Great!
Acked-by: Stefan Reinauer stepan@coresystems.de
On Fri, Mar 20, 2009 at 6:18 AM, Stefan Reinauer stepan@coresystems.de wrote:
On 19.03.2009 22:21 Uhr, Myles Watson wrote:
That fixes it for me. Patch attached.
Signed-off-by: Myles Watson mylesgw@gmail.com
Great!
Acked-by: Stefan Reinauer stepan@coresystems.de
Rev 4023.
Thanks, Myles
On Wed, Mar 18, 2009 at 01:01:41PM -0700, ron minnich wrote:
are the payloads built with omit frame pointer?
it's not a good thing if we have to sync how payloads are built with how coreboot is built.
SeaBIOS does use -fomit-frame-pointer (enabling it provides noticably better code generation). However, I don't think this is related to the payload at all. The frame-pointer option controls what gcc puts into %ebp, and SeaBIOS doesn't care at all what's in that register when it is launched.
-Kevin
On Wed, Mar 18, 2009 at 1:17 PM, Kevin O'Connor kevin@koconnor.net wrote:
On Wed, Mar 18, 2009 at 01:01:41PM -0700, ron minnich wrote:
are the payloads built with omit frame pointer?
it's not a good thing if we have to sync how payloads are built with how coreboot is built.
SeaBIOS does use -fomit-frame-pointer (enabling it provides noticably better code generation). However, I don't think this is related to the payload at all. The frame-pointer option controls what gcc puts into %ebp, and SeaBIOS doesn't care at all what's in that register when it is launched.
yes, we may still be looking at a symptom of a different problem
ron
On Wed, Mar 18, 2009 at 2:23 PM, ron minnich rminnich@gmail.com wrote:
On Wed, Mar 18, 2009 at 1:17 PM, Kevin O'Connor kevin@koconnor.net wrote:
On Wed, Mar 18, 2009 at 01:01:41PM -0700, ron minnich wrote:
are the payloads built with omit frame pointer?
it's not a good thing if we have to sync how payloads are built with how coreboot is built.
SeaBIOS does use -fomit-frame-pointer (enabling it provides noticably better code generation). However, I don't think this is related to the payload at all. The frame-pointer option controls what gcc puts into %ebp, and SeaBIOS doesn't care at all what's in that register when it is launched.
yes, we may still be looking at a symptom of a different problem
Maybe we should be asking for successes instead of failures. Has anyone been able to boot any payload with v2 and -fomit-frame-pointer?
Thanks, Myles
On Wed, 18 Mar 2009 14:25:55 -0600, Myles Watson mylesgw@gmail.com wrote:
On Wed, Mar 18, 2009 at 2:23 PM, ron minnich rminnich@gmail.com wrote:
On Wed, Mar 18, 2009 at 1:17 PM, Kevin O'Connor kevin@koconnor.net
wrote:
On Wed, Mar 18, 2009 at 01:01:41PM -0700, ron minnich wrote:
are the payloads built with omit frame pointer?
it's not a good thing if we have to sync how payloads are built with how coreboot is built.
SeaBIOS does use -fomit-frame-pointer (enabling it provides noticably better code generation). However, I don't think this is related to the payload at all. The frame-pointer option controls what gcc puts into %ebp, and SeaBIOS doesn't care at all what's in that register when it is launched.
yes, we may still be looking at a symptom of a different problem
Maybe we should be asking for successes instead of failures. Has anyone been able to boot any payload with v2 and -fomit-frame-pointer?
If it is in the FILO CC flags, I built it the other day, and it is booting just fine for me.
Myles Watson wrote:
Maybe we should be asking for successes instead of failures. Has anyone been able to boot any payload with v2 and -fomit-frame-pointer?
Yes, it seems to work fine for everyone except Ubuntu 8.10 users.
On Thu, Mar 19, 2009 at 01:50:48AM +0100, Stefan Reinauer wrote:
Myles Watson wrote:
Maybe we should be asking for successes instead of failures. Has anyone been able to boot any payload with v2 and -fomit-frame-pointer?
Yes, it seems to work fine for everyone except Ubuntu 8.10 users.
It's broken on FC10 also.
-Kevin
On Wed, Mar 18, 2009 at 09:47:44PM -0400, Kevin O'Connor wrote:
On Thu, Mar 19, 2009 at 01:50:48AM +0100, Stefan Reinauer wrote:
Myles Watson wrote:
Maybe we should be asking for successes instead of failures. Has anyone been able to boot any payload with v2 and -fomit-frame-pointer?
Yes, it seems to work fine for everyone except Ubuntu 8.10 users.
It's broken on FC10 also.
Is that also gcc 4.3.X? Stepan, what gcc version are you using?
Thanks, Ward.
On Wed, Mar 18, 2009 at 09:50:47PM -0400, Ward Vandewege wrote:
On Wed, Mar 18, 2009 at 09:47:44PM -0400, Kevin O'Connor wrote:
On Thu, Mar 19, 2009 at 01:50:48AM +0100, Stefan Reinauer wrote:
Myles Watson wrote:
Maybe we should be asking for successes instead of failures. Has anyone been able to boot any payload with v2 and -fomit-frame-pointer?
Yes, it seems to work fine for everyone except Ubuntu 8.10 users.
It's broken on FC10 also.
Is that also gcc 4.3.X? Stepan, what gcc version are you using?
$ gcc --version gcc (GCC) 4.3.2 20081105 (Red Hat 4.3.2-7) Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-Kevin
On 19.03.2009 2:50 Uhr, Ward Vandewege wrote:
On Wed, Mar 18, 2009 at 09:47:44PM -0400, Kevin O'Connor wrote:
On Thu, Mar 19, 2009 at 01:50:48AM +0100, Stefan Reinauer wrote:
Myles Watson wrote:
Maybe we should be asking for successes instead of failures. Has anyone been able to boot any payload with v2 and -fomit-frame-pointer?
Yes, it seems to work fine for everyone except Ubuntu 8.10 users.
It's broken on FC10 also.
Is that also gcc 4.3.X? Stepan, what gcc version are you using?
4.3.2 vanilla
-
Joseph Smith -
Kevin O'Connor -
Myles Watson -
ron minnich -
Stefan Reinauer -
Ward Vandewege