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 -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
