Philippe Gerum wrote:
> On Thu, 2010-06-03 at 08:55 +0200, Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> Hi all,
>>>> here is the first apparently working prototype for getting hold of
>>>> endless user space loops in RT threads. A simple test case of mine now
>>>> receive a SIGDEBUG even if it does "while (1);".
>>>> The design follows Gilles' suggestion to force a SEGV on victim thread
>>>> but restore the patched PC before migrating the thread after this fault.
>>>> The only drawback of this approach: We need to keep track of the
>>>> preempted register set at I-pipe level. I basically replicated what
>>>> Linux does these days as well and exported it as ipipe_get_irq_regs()
>>>> (the second patch).
>>> You already have the regs in xnarch_fault_info.
>> We only pass this around for exceptions.
> And for a good reason, exceptions are always delivered synchronously
> upon receipt, not IRQs, given the deferred dispatching scheme. Your
> ipipe_get_irq_regs interface is inherently broken for anything which is
> not a wired-mode timer IRQ, since you could pass the caller a reference
> to an unwound stack frame.

It may not work for certain deferred IRQs, true, but then it will return
NULL. The user of ipipe_get_irq_regs has to take this into account. And
most consumers will be wired IRQ handler anyway.

> You have to resort to __ipipe_tick_regs, and obviously only use this in
> the context of a timer-triggered code, like the watchdog handler, which
> saves your day.

Doesn't work if the timer IRQ is not the host tick AND doesn't help us
modifying the return path.

Granted, the former scenario is already broken in I-pipe (try using an
x86 host with an MSI-capable HPET...), but the latter is definitely a no-go.


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to