-
Philippe Gerum authored
Ptracing may cause timer overruns, as the ptraced application cannot go waiting for the current period in a timely manner when stopped on a breakpoint or single-stepped. A mechanism was introduced a long time ago for hiding those overruns from the application, while ptracing is in effect. The current implementation dealing with this case has two major flaws: - it crashes the system when single-stepping (observed on ARM i.MX6q), revealing a past regression which went unnoticed so far. - it uses a big hammer to forward (most) timers without running their respective timeout handler while ptracing, in order to hide this timespan from the overrun accounting code. This introduces two issues: * the timer forwarding code sits in the tick announcement code, which is a very hot path, despite ptracing an application is definitely not a common operation. * all timers are affected / blocked during ptracing, except those which have been specifically marked (XNTIMER_NOBLCK) at creation, which turns out to be impractical for the common case. The new implementation only addresses what is at stake, i.e. hiding overrun reports due to ptracing from applications. This can be done simply by noting when a thread should disregard overruns after an exit from the ptraced mode (XNHICCUP), then discard the pending overruns if this flag is detected by the code reporting them (xntimer_get_overrun()).
9ebc2b6e