[Xenomai] Mayday issues again

[Jan Kiszka <jan.kiszka@web.de>]

Hi Philippe,

the mayday mechanism is causing troubles to me again.

First of all, there is a bug /wrt restarting the mayday syscall. We
current don't restart on pending signals, thus destroy the register of
the interrupted thread that contains the syscall return code. See my
for-forge branch for a fix proposal.

But actually I would like to get rid of the syscall trampoline
completely if somehow possible, at least for certain archs. The reason
is that it ruins debuggability. If a RT thread is stopped by gdb with
the help of the mayday mechanism, it ends up waiting for resumption on
the mayday page. Even worse, backtracing is broken, at least on x86.

That brings me to the key question: why do we need the syscall
trampoline? We set TIP_MAYDAY in the target task, the task causes
IPIPE_TRAP_MAYDAY to be reported via the trap hook, the hook sets the
trampoline code, the trampoline triggers the syscall, and only on
syscall return, we finally migrate the task to Linux. What prevents
doing the migration already in the trap hook, ie. in
handle_mayday_event? The pattern seems similar to the migration we
trigger on userspace faults. And it seems to works, at least for x86,
and doesn't have the unwanted side effects.

The background of this work is improving gdb support, in particular
deterministic stopping and resuming of multi-threaded RT processes. I'm
still in the design & prototype phase, RFC patches will follow later.

Jan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://xenomai.org/pipermail/xenomai/attachments/20150620/34f24c6e/attachment.sig>