Michael Devore wrote:
At 06:53 AM 7/24/2005 +0200, Eric Auer wrote:
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?),
because that is not how I want people to get to it, they should go
through freedos.sourceforge.net/kernel and only then visit
fdos.org/kernel, so should we finally get a new kernel maintainer
(remember I'm only the interim one) he/she can update the sf page and
people will get the correct content. Sure I plan to keep the
fdos.org/kernel page for years and doesn't look like anyone is jumping
to be our kernel maintainer, but hey it could happen. :-)
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 :-).
Could be right, might be right, sound's good...And yet you really don't
know. Well, let's just think about this for a second. How could you
test something to demonstrate that you can follow-up on your
suppositions. Hmm. Oh, I know. You could save and restore the GS
register in the failing kernel call to see whether it is critical. That
would take a couple of minutes.
Or you could recompile the kernel with the different options you
listed. Another few minutes.
When you do that and verify the problem, get back to me on it, okay?
Good deal.
Problem verified; the OW 386 kernel build really does need GS preserved
(at least using current build settings) and it is not (or at least
adding a push/pop GS before the call far to the interrupt routine stops
the crash after loading emm386). I have committed a workaround in the
stable kernel sources for now (so it should be safe to use it and emm386
for now). My question is, does any other software destroy important
registers? or stated another way, even if emm386 is changed to not alter
gs between call/return, should we still protect the important 386
registers from other drivers behaving similarly? Note: I used the
existing Protect/Restore 386Registers macro to possibly help ensure
safety of/from other compilers/future drivers.
thanks,
Jeremy
-------------------------------------------------------
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
