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