Like this?Going back in time? Ask the kernel to fix the issue.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.
But this is just too many ugly code for nothing.Why not? The safest general way to detect new features is to try to use them.Umm, nope.Good, but have you added any flag for dosemu to even knowYou could probe for it directly: raise a signal, change the saved ss
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.
But the delivery can be easily checked with "if (ss & 4)".I still don't see how sigreturn matters here. It's signal *delivery*Let me see if I can come up with a clean kernel fix.The check for proper sigreturn would be good.
that's the problem.
I'm thinking of having signal delivery zap ss only if the old ss looksI am not sure how good is this.
bogus instead of zapping it unconditionally. IOW, instead of setting
regs->ss = __USER_DS unconditionally, we'd do larl on the old regs->ss
and keep it if it's DPL 3 RW data (exp-down or otherwise) and present.
I'll have to check the precise rules in both the SDM and APM. TheWell, this is a "very basic" idea, so to say.
idea is that we don't want IRET to fail during signal delivery, which
can happen due to a bad sigreturn or a race against modify_ldt.