On 2012-03-19 01:29, Kevin O'Connor wrote:
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?
This makes no difference here, still 216 bytes.
Jan