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. Jan
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomaifirstname.lastname@example.org https://mail.gna.org/listinfo/xenomai-core