Re: intr-msg / hurdsig looks broken, is my analysis correct?

[Sergey Bugaev]

So I implemented this, and it seems to work — as in, signals arrive
and handlers run. It's extremely unlikely that I managed to hit the
interesting code path where eip is inside that piece of code, so who
knows whether that works or not — especially given this has been
apparently broken in glibc for years and nobody noticed.

But I'm not sending the patch; that's because I've got a much better idea now:

let's not do any of this at all! :)

Really, why would it matter whether eip is after
_hurd_intr_rpc_msg_about_to or not? What if it's 1 instruction before
that? We skip the call, pretending it was interrupted, but does it
really matter that we do that — can't we just admit that the signal
arrived before the call, after all that's exactly how it would look if
we catch the thread before it enters _hurd_intr_rpc_msg_about_to?

The answer, I think, is that the ecx kludge was the reason this code
in hurdsig.c and trampoline.c exists in the first place, since they
need to be aware and restore esp appropriately. It's not related to
skipping the message trap at all, it's only really about handling the
fact that the stack pointer is incorrect. Any other code that would
temporarily set esp to below the actual tip of the stack — no RPCing
needs to be involved — would need similar special-casing in these two
files.

And so since 1d20f33ff4fb634310f27493b7b87d0b20f4a0b0 has dropped the
root cause of the kludge, _all of this code_ can be dropped too.

I will un-implement that and see whether that really works; in the
meantime — does this make sense?

Sergey