On 08/02/2017 06:06 PM, Jan Kiszka wrote: > On 2017-08-02 17:57, Philippe Gerum wrote: >> On 08/02/2017 05:43 PM, Jan Kiszka wrote: >>> On 2017-08-02 15:05, Philippe Gerum wrote: >>>> On 08/02/2017 02:54 PM, Jan Kiszka wrote: >>>>> On 2017-08-02 14:47, Philippe Gerum wrote: >>>>>> 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. >>>>>> >>>>> >>>>> Will have a look. >>>>> >>> >>> The approach looks good, but please split up refactorings from the >>> functional change - reviewing and also cherry-picking the patch is hard >>> now (I will need to keep some structuring for the rtdebug patches below). >>> >> >> Except for a single comment being reworded, the rest is a drop-in >> replacement for the previous approach, there is no refactoring. I can >> remove the former implementation, then add the new one in a separate >> patch if that helps. > > The removal of register_debugged_thread is refactoring (I will have to > reintroduce it). >
register_debugged_thread() contained a two-liner which became a one-liner in the new implementation. I don't see the inlining of such one-liner as losing any information about the implementation. > Some of the changes to print_core_clock_status seem to be cleanups as > well, though triggered by the removal of nklock. They don't affect me, > just seemed cleaner to me to break them up. > These are no cleanups. The timer status has no meaning if the time base cannot be locked anymore. -- Philippe. _______________________________________________ Xenomai mailing list [email protected] https://xenomai.org/mailman/listinfo/xenomai
