Hi, I have done some heavy Bochs-debugging, hunting
down the reason why our 386-optimized kernels crash
when you use FreeDOS EMM386. The short reason: From
the (#-9-#) label on, EMM386 trashes MANY 386-specific
registers while go_driver_entry only saves 8086-specific
registers around the call to go_driver, which contains
the (#-9-#) and following code.
go_driver -> ... -> go_protected --taskswitch--> v86_start --iretd-->
keep -> ... (it was really hard to understand that part of the code,
as it is not well commented in the sources)
In the end, EMM386 returns, and execrh() (see INIT_EXECRH in
the FreeDOS kernel source) can complete. But watch this: We
enter execrh() with:
eax:0x00007e02, ebx:0x00000000, ecx:0x00060fe2, edx:0x00001928
ebp:0x00001950, esp:0x00001920, esi:0x00000000, edi:0x00000fe2
eip:0x0000b3c5, eflags:0x00000202, inhibit_mask:0
cs=0x911b ss=0x9e24 ds=0x9e24 es=0x00d0 fs=0x00d0 gs=0x0308 ldtr=0 tr=0
gdtr=none idtr=none cr0=0x10 cr1=0 cr2=0 cr3=0 cr4=0
but then we return we have:
eax:0xf5fc0021, ebx:0x00001928, ecx:0x00000fe2, edx:0x00001928
---- ----
ebp:0x00001950, esp:0x00001928, esi:0x00000000, edi:0x00000fe2
eip:0x0000b3c8, eflags:0x00023202, inhibit_mask:0
cs=0x911b ss=0x9e24 ds=0x9e24 es=0x9e24 fs=0x0000 gs=0x0000 ldtr=8 tr=10
---- ---- ----
gdtr=0x3ae4/0x7f idtr=0x124658/0x7ff cr0=0x80000011 cr1=0 cr2=0
cr3=0x00125000 cr4=0
The underlined things spoil the fun for OpenWatcom. The other diffs do
not hurt, as they only mean "system switched to v86 mode".
It is EXECRH itself which breaks ES between call and return, so I do
assume that the OpenWatcom kernel can somehow live with that, as ONLY
EMM386 triggers the crash. Left options for the troublemakers are:
EAX/high, ECX/high, FS, GS
I think the answer is: OpenWatcom needs GS to be preserved.
One "ret +4" later, we reach the following code (sorry for the
bad dump format, my Bochs is not the newest version...) -->
0009d711: ( ): mov word ptr ss:[bp+0xfffc], ax ; 8946fc
0009d714: ( ): test ax, ax ; 85c0
0009d716: ( ): jnz .+0xd740 ; 7528
0009d718: ( ): mov bx, di ; 89fb
0009d71a: ( ): mov ax, word ptr gs:[bx] ; 658b07
...
The code before that makes NO attempt to set GS to some value,
so the compiler depends on the value to be preserved over the EXECRH.
Unfortunately Bochs does not allow me to use "r gs = ..." to fix the GS
value, but I think the broken GS is what kills the kernel here.
Note that EMM386 does at least modify EAX EBX ECX EDI ESI EBP
without saving them during the driver initialization, it is just
random luck that most of them had the high half at the same value 0
between entry and return from the driver initialization code.
I would also recommend - apart from "go_driver_entry must save
the 386-specific registers, optimally after checking whether the
CPU is 386, and if not, refusing to call go_driver at all (!)" - to
modify the EXECRHM macro in the kernel to preserve the ES contents
of the caller! Yet EMM386 is in the unlucky situation that, while
the kernel trashing ES is certainly not elegant, only EMM386 trashing
GS causes an actual crash. Some comment in the kernel sources states
that OpenWatcom does not use the high part of the 386 registers at
all (???) but indeed relies on FS: and GS:, but this seems to happen
only when you use the -zff and -zgf compiler options.
So for a quick check, you can remove the -zff and -zgf from our
kernel makefile to see if that makes the kernel "EMM386 2.04 immune".
Tests done with FreeDOS devel kernel, 386-optimized, from
http://fdos.org/kernel/ (which is STILL not linked from
http://fdos.org/ nor from http://www.freedos.org/ - WHY?),
dated Jul 23 2005 1.1.35w 2035w-UNSTABLE, DOS 7.10 WATCOMC 80386 FAT32.
Luckily the fix for EMM386 only consists of some extra push/pop :-).
Eric
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
