On 08/02/2017 01:03 PM, Jan Kiszka wrote: > On 2017-08-02 10:12, Philippe Gerum wrote: >> On 07/27/2017 08:03 PM, Jan Kiszka wrote: >>> Hi, >>> >>> currently, when gdb interrupts a Xenomai application, all timers stop >>> firing (except for those marked with XNTIMER_NOBLCK - core timers). This >>> means, you can't debug one RT application without affecting others on >>> the same systems. I'm not wondering how to resolve this. Options: >>> >>> - convert timer stopping to a per-process feature - implies the need to >>> establish some timer-process relationship concept, and it might be >>> tricky for drivers and other central timer creators >>> >>> - let the application deal with timer overflows during debug: >>> - make timer stop optional (in case of single applications that >>> can't handle this yet) >>> - do not stop timers at all >>> >>> Any opinions? >>> >> >> That stuff is a relic from the Dark Ages, which not only sits in a hot >> path, but also crashes an ARM board here when ptracing. At the very >> least, the implementation is overkill and needs fixing. >> >> I'm working on a much simpler and less intrusive approach, I'll follow >> up today on this. > > OK, looking forward.
To answer your original question, I would either let the application deal with overruns, or provide an implementation that only cares for hiding overruns that may have occurred due to ptracing, instead of trying to somehow freeze time. So I pushed an implementation doing exactly that, fixing the breakage issue in the same move. There is no such thing as blocked timers anymore, we just pretend that no overrun took place when asked via xntimer_get_overrun() after a ptraced state has existed, until an originally relaxed caller eventually leaves the kernel in primary mode, at which point normal accounting is restarted. That should exactly cover the case we are interested in, i.e. a once ptraced - therefore relaxed - thread, returning from any service which may collect the overrun count, and has to do so from primary mode (e.g. sigwait(), timerfd.read(), rtdm_task_wait_period()). The code is in wip/sstep for now. > >> >>> BTW, I also have pre/post-debug hook concept for applications out of >>> tree that can help to make applications debug-aware. In our use cases, >>> the pre-hook brings hardware into a state that permits application stop, >>> and the post-host ramps everything up again. >>> >> >> Hooks sitting in kernel space? >> > > No, in the application. They are running in a "privileged" carrier > thread (privileged means that it is stopped only after the callback > finished). Goes along with changes to enable synchronous stopping of all > RT threads (except that one) once a debug-stop comes in. > Maybe that could be generalized by defining a special signal some dedicated thread within an application could sigwait() for. A thread synchronously waiting for such signal would inherit the required privileges by doing so. -- Philippe. _______________________________________________ Xenomai mailing list [email protected] https://xenomai.org/mailman/listinfo/xenomai
