On Mon, Feb 27, 2012 at 04:25:09PM +0100, Jan Kiszka wrote: > On 2012-02-27 10:51, Daniel P. Berrange wrote: > > I'm seeing current QEMU GIT fail to boot MS-Dos 6.22 with the following > > crash: > > > > # qemu-system-x86_64 -fda ~/MS-DOS\ 6.22.img -m 1 -curses > > iPXE v1.0.0-591-g7aee315 > > iPXE (http://ipxe.org) 00:03.0 C900 > > PCI2.10 PnP PMM+00000000+00000000 C900 > > > > Booting from Floppy.. > > . qemu: fatal: Trying to execute code > > outside RAM or ROM at 0x00000001000effff > > > > EAX=ffffffff EBX=ffffffff ECX=0000c934 EDX=00000068 > > ESI=00006801 EDI=00000000 EBP=0000002b ESP=0000fff5
I traced this down, and it appears to be a stack size issue. It looks like MSDOS calls "int 0x13" with 229 bytes of stack space during its boot. On my build gcc generates the handle_13() function with a maximum of 140 bytes of stack space utilized (according to tools/checkstack.py). On your build, gcc created it with a maximum of 216 bytes. The entry functions use 42 bytes of stack space. Add it up and you can see that the additional stack space that gcc used caused %esp to wrap and the stack was corrupted. I'm not sure how to best work around this. One way is to sprinkle "noinline" keywords through disk.c. (It seems like gcc got in trouble on your build by inlining many functions into disk_13().) Another way would be to jump into the extra stack (the disk code already uses its own stack) earlier in the handle_13 code. Also, can you see what happens if you change "--param large-stack-frame=4" to "--param large-stack-frame=0" in the build? -Kevin
