On 2017-08-02 18:17, Philippe Gerum wrote: > 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).
And the corresponding unregister_debugged_thread will also be needed again, including a call site that is - granted - not required for the upstream code right now. > > 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. We have more one-liners that semantically wrap some trivial state changes. It would have just helped the upcoming patches and focused this change on the semantical differences. /me is writing a partial revert patch then. Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux _______________________________________________ Xenomai mailing list [email protected] https://xenomai.org/mailman/listinfo/xenomai
