On Wed, Aug 12, 2015 at 1:02 AM, Stas Sergeev <stsp@xxxxxxx> wrote:Without it, dosemu stores and fetches the ss value
12.08.2015 03:38, Andy Lutomirski ÐÐÑÐÑ:To be fair, I renamed a field that used to be padding. The UAPI has
On Tue, Aug 11, 2015 at 5:17 PM, Stas Sergeev <stsp@xxxxxxx> wrote:You changed include/uapi/*, which is obviously an asking
Hi guys, I wonder how easily the include/uapi/* is beingI didn't anticipate any breakage. I could have been wrong.
changed these days.
breaks dosemu (and perhaps everyone else who used
to restore the segregs by hands). And the fix involves
both autoconf magic and run-time magic, so it is not even
I realize this patch may be good to have in general, but
breaking userspace without a single warning is a bit
discouraging. Seems like the old "we don't break userspace"
rule have gone.
for problems. I applied the following changes to my local
git tree to get dosemu working again:
to change on occasion -- it's just not supposed to break things.
https://github.com/stsp/dosemu2/commit/48b2a13a49a9fe1a456cd77df6b9a1feec675a01Maybe I'm still missing something, but this seems like it should be
unnecessary. What goes wrong without it?
What else it could do? :(https://github.com/stsp/dosemu2/commit/7898ac60d5e569964127d6cc48f592caecd20b81So the problem is that dosemu was actually hacking around the old
buggy behavior and thus relying on it. Grr.
I thought you mean some per-process flag that wouldIt wouldn't even help here, because the breakage isn't caused byWe might still be able to require a new sigcontext flag to be set andWell, the flag would be an ideal solution in an ideal world,
to forcibly return to __USER_DS if the flag is set regardless of the
ss value in sigcontext when sigreturn is called, if that is indeed the
problem with DOSEMU. But I'm not actually sure that that's the
but in our world I don't know the current relevance of dosemu,
and whether or not it worth a new flag to add.
incompatible sigcontext formats -- it's caused by dosemu's reliance on
ss being preserved across signal delivery
(even if it wasn't preservedHow so?
on the way back).
Umm, nope.You could probe for it directly: raise a signal, change the saved ssIn fact, DOSEMU contains this:Good, but have you added any flag for dosemu to even know
/* set up a frame to get back to DPMI via iret. The kernel does not
%ss, and the SYSCALL instruction in sigreturn() destroys it.
IRET pops off everything in 64-bit mode even if the privilege
does not change which is nice, but clobbers the high 48 bits
of rsp if the DPMI client uses a 16-bit stack which is not so
nice (see EMUfailure.txt). Setting %rsp to 0x100000000 so that
bits 16-31 are zero works around this problem, as DPMI code
can't see bits 32-63 anyway.
So, if DOSEMU were to realize that both sigreturnissues it's
complaining about are fixed in recent kernels, it could sigreturn
directly back to any state.
it can do this? Unless I am mistaken, you didn't. So the fix you
suggest, is not easy to detect and make portable with the older
kernels. Any suggestions?
and see what's in ss after sigreturn.
Let me see if I can come up with a clean kernel fix.The check for proper sigreturn would be good.