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. -- Philippe. _______________________________________________ Xenomai mailing list [email protected] https://xenomai.org/mailman/listinfo/xenomai
