Gilles Chanteperdrix wrote: > Philippe Gerum wrote: >> On Wed, 2010-06-02 at 10:36 +0200, Gilles Chanteperdrix wrote: >>> Jan Kiszka wrote: >>>> Tschaeche IT-Services wrote: >>>>> On Tue, Jun 01, 2010 at 04:32:37PM +0200, Philippe Gerum wrote: >>>>>> Not in the absence of syscall. We thought about this once already, when >>>>>> considering how a watchdog preempting a runaway task in primary mode >>>>>> could force a secondary mode switch: there is no sane and easy solution >>>>>> to this unfortunately. >>>>> This is exactly Sigmatek's problem: Our customers develop code >>>>> within our debugging/development environment. We want to catch >>>>> this situation (the developer implements a while(1)) with a >>>>> watchdog throwing SIGTRAP so that our debugger gets active >>>>> and can locate the problem according to the stack frame... >>>> CONFIG_XENO_OPT_WATCHDOG is probably what you are looking for. It tries >>>> to catch "well-behaving" broken threads via SIGDEBUG and kills the >>>> hopelessly broken rest - system alive again. >>>> >>>> You can then debug the former and need to do code review on the latter. >>>> Or you could also try to add some loop-breaking Xenomai syscalls (or >>>> even more clever checks) to library services the code under suspect >>>> usually invokes. >>> I am afraid "well-behaving" means emitting syscalls. We have a radical >>> way to cause a SIGSEGV to be sent to a thread having run amok: set its >>> PC to an invalid address (after having printed the real PC). gdb will >>> not be able to print where the program stopped, but should be able to >>> print the backtrace. >>> >> Actually, we could extend this logic and forge a stack frame to return >> to the preempted application code via some userland trampoline code, >> doing the switch: >> >> [watchdog trigger] >> forge_return_frame(on =regs->sp, to =regs->pc); >> regs->pc = __oops_I_did_it_again; >> >> __oops_I_did_it_again: >> __xn_migrate(LINUX_DOMAIN); >> ret (via forged frame) >> >> The thing is, that this brings in some arch-dep code to forge a stack >> frame (like the kernel uses for signals), that should rather live in the >> pipeline core. > > There seems to be a simple approach: > when the thread runs amok, set the pc to invalid address, save the real > pc somewhere > when relaxing for handling the exception (xnpod_trap_fault), if the amok > bit is set, restore the pc in the saved registers from the saved location.
Sounds feasible, will give it a try. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
