On Wed, Sep 2, 2015 at 11:23 AM, Stas Sergeev <stsp@xxxxxxx> wrote:dosemu needs 2 return pathes:
02.09.2015 21:17, Andy Lutomirski ÐÐÑÐÑ:What's the exact siglongjmp usage you have in mind? Signal context
On Wed, Sep 2, 2015 at 10:46 AM, Stas Sergeev <stsp@xxxxxxx> wrote:Could you please clarify?
02.09.2015 17:21, Andy Lutomirski ÐÐÑÐÑ:This seems like it would be relying unpleasantly heavily on libc internals.
I am not saying siglongjmp() will be affected.What's the issue here? I don't understand.This should work for old DOSEMU. It's a bit gross, but it has thePros:
nice benefit that everyone (even things that aren't DOSEMU) gain the
ability to catch signals thrown from bogus SS contexts, which probably
improves debugability. It's also nice to not have the SA flag.
- No new SA flag
- May improve debugability in some unknown scenario where people
do not want to just use the new flag to get their things improved
- Does not allow to cleanly use siglongjmp(), as then there is a risk
to jump to 64bit code with bad SS
On musl, (sig)longjmp just restores rsp, rbx, rbp, and r12-r15, so it
won't be affected. AFAIK all implementations of siglongjmp are likely
to call sigprocmask or similar, and that will clobber SS. I'm not
aware of an implementation of siglongjmp that uses sigreturn.
Quite the opposite: it won't, which is bad. :)
If you have always correct SS, you can use siglongjmp(). If you have
broken SS at times, siglongjmp() will be an asking for troubles, as
it exactly does not restore SS.
dosemu could do a good use of siglongjmp() to get back to 64bit code
from its sighandler.
If kernel always passes the right SS to the sighandler, then what's
isn't normally involved AFAIK.
Hmm? IIRC you've just said this:I'm still not understanding what you're looking for. If youExcept for passing the SS=__USER_DS to the sighandler, for which we*I* can't do anything to siglongjmp because that's almost entirelyYes, and as such, they should be blocked.- Async signals can silently "validate" SS behind your backTrue, and that's unfortunate. But async signals without SA_SAVE_SS
set with the other approach have exactly the same problem.
You could improve on that and on siglongjmp().
And on TLS in the future.
outside the kernel. :-/
discussed the new SA_hyz?
siglongjmp out of a signal handler, the hardware SS value is
irrelevant, at least on 64-bit binaries, because siglongjmp is just
going to replace it.
... add the SA_hyz flag.For 64-bit delivery, ignoring backwards compatibility, deliveringI am much more bothered with delivering the right SS than withThat could work. The result is quite similar to explicitly settingSurely, but how about then having the heuristics you suggest,Is the new SA flag such a big deal here to even bother?Not really, but given that the new behavior seems clearly better
behaved than the old, it would be nice to be able to have the good
behavior, or at least most of it, be the default.
only if the new SA_hyz is not set? And when it is set, have a
properly defined and predictable behaviour. Then it seems like
we'll get all the possible wishes covered.
restoring it on sigreturn().
signals with ss = __USER_DS would be the right solution, I think: it's
trivial and it works. Because of backwards compatibility, we need to