On 16/04/2012, Stas Sergeev wrote: > Then maybe you should at least check whether the saved > value was actually zero, and print an error if not.
which saved value? Anyway there are a few issues for x86-64: - you can't sigreturn() to DPMI code (i.e., the indirect DPMI switch, "call sigreturn()" or dropping out of a signal handler), because that involves calling SYSCALL which destroys %ss. The kernel does not save and restore %ss (the kernel's sigcontext has no entry for it). - this means you always have to do a direct switch, including when TF is set. - iret does this switch atomically with respect to TF. There used to be a different switch which used LSS (or rather mov ss,...), when I first did the x86-64 port, but I changed it to use iret to fix TF behaviour and in general it was cleaner (see svn diff -r1619:1620). > But: this all is very questionable. > I mean, there is a kernel, which will trash ESP asynchronously > anyway. So was there any use to do all that recovery to just > have the ESP screwed up by the kernel a microsecond later? It's only a problem if DOSEMU just caught a stack fault and adjust by zeroing out the high bits of esp. If you don't clear bits 16-31, you'll stack fault again, immediately, unless you actually emulate the offending instruction. svn rev 1793 fixes x86-64 for Need for Speed and the ancient MS linker but of course it's never 100% reliable. > Of course if there is a hope to have an in-kernel workaround too, > then yes. When I brought it up several years ago Andi Kleen wasn't very keen to accept these kind of kernel adjustments... Bart ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Dosemu-devel mailing list Dosemu-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dosemu-devel
