Re: [Xenomai-core] [PATCH] Optional timer freeze during ptracing
Jan Kiszka wrote: Freezing all Xenomai timers while just a single RT application is under ptrace control can be helpful in certain debugging scenarios, but it can as well be harmful when other parts of the systems have to continue to work. I brought this concern up back in 2006, and I originally thought we may address this by freezing per process. But this is far too complex for a simple problem like this: Just make the whole thing configurable, and keep it off by default so that -ideally- only users who are aware of the side effects will arm it. Gilles, you recently stumbled over such a side effect and introduced XNTIMER_NOBLCK (for customized timer instrumentations as far as I understood this). Do you think we still need that knob when we have CONFIG_XENO_OPT_PTRACE_TIMER_FREEZE? Yes, the feature allowing to block all timers makes my debugging possible, so I want it, except for one timer. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Optional timer freeze during ptracing
Jan Kiszka wrote: Freezing all Xenomai timers while just a single RT application is under ptrace control can be helpful in certain debugging scenarios, but it can as well be harmful when other parts of the systems have to continue to work. I brought this concern up back in 2006, and I originally thought we may address this by freezing per process. But this is far too complex for a simple problem like this: Just make the whole thing configurable, and keep it off by default so that -ideally- only users who are aware of the side effects will arm it. No, it's the other way around, you know when you don't want a timer to be blocked because it serves some purpose that goes beyond the application duty, like keeping a RTnet connection alive through which you happen to debug; on the other hand, all other timers relate to the logic the application implements, so you most often want them to track the debugging state so that they don't mess up behind you back when the debugger halts the application. Blocking timers during ptracing should be on by default, no need to break a known behaviour Xenomai had for ages for rare cases when some of them are also used to maintain some external activity alive. This is the exception, and as such, those timers should be marked as non-blockable in the code that defines them; a global knob may then switch them to blockable if needed. An intermediate approach would be to force the threads ptimer and rtimer as blockable ones, and use a global flag to switch the rest as non-blockable, albeit this may cause non-related watchdogs to keep triggering, which most of the time could be a real pain in the neck when debugging. Gilles, you recently stumbled over such a side effect and introduced XNTIMER_NOBLCK (for customized timer instrumentations as far as I understood this). Do you think we still need that knob when we have CONFIG_XENO_OPT_PTRACE_TIMER_FREEZE? Jan ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Optional timer freeze during ptracing
Philippe Gerum wrote: Jan Kiszka wrote: Freezing all Xenomai timers while just a single RT application is under ptrace control can be helpful in certain debugging scenarios, but it can as well be harmful when other parts of the systems have to continue to work. I brought this concern up back in 2006, and I originally thought we may address this by freezing per process. But this is far too complex for a simple problem like this: Just make the whole thing configurable, and keep it off by default so that -ideally- only users who are aware of the side effects will arm it. No, it's the other way around, you know when you don't want a timer to be blocked because it serves some purpose that goes beyond the application duty, like keeping a RTnet connection alive through which you happen to debug; on the other hand, all other timers relate to the logic the application implements, so you most often want them to track the debugging state so that they don't mess up behind you back when the debugger halts the application. Blocking timers during ptracing should be on by default, no need to break a known behaviour Xenomai had for ages for rare cases when some of them are also used to maintain some external activity alive. This is the exception, and as such, those timers should be marked as non-blockable in the code that defines them; a global knob may then switch them to blockable if needed. You focus on single application, or single function per system. Moreover, following this logic, you would have to suppress all interrupts as well while ptracing some app. An intermediate approach would be to force the threads ptimer and rtimer as blockable ones, and use a global flag to switch the rest as non-blockable, albeit this may cause non-related watchdogs to keep triggering, which most of the time could be a real pain in the neck when debugging. That' sounds better, specifically switching to a XNTIMER_BLCK logic. What about freezing the ptimer and rtimers of all xnthreads in ptraced processes? That shouldn't require us to track additional information in xntimer_t about its owner. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Optional timer freeze during ptracing
Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Freezing all Xenomai timers while just a single RT application is under ptrace control can be helpful in certain debugging scenarios, but it can as well be harmful when other parts of the systems have to continue to work. I brought this concern up back in 2006, and I originally thought we may address this by freezing per process. But this is far too complex for a simple problem like this: Just make the whole thing configurable, and keep it off by default so that -ideally- only users who are aware of the side effects will arm it. No, it's the other way around, you know when you don't want a timer to be blocked because it serves some purpose that goes beyond the application duty, like keeping a RTnet connection alive through which you happen to debug; on the other hand, all other timers relate to the logic the application implements, so you most often want them to track the debugging state so that they don't mess up behind you back when the debugger halts the application. Blocking timers during ptracing should be on by default, no need to break a known behaviour Xenomai had for ages for rare cases when some of them are also used to maintain some external activity alive. This is the exception, and as such, those timers should be marked as non-blockable in the code that defines them; a global knob may then switch them to blockable if needed. You focus on single application, or single function per system. Moreover, following this logic, you would have to suppress all interrupts as well while ptracing some app. I focus on what's most frequent among users: a single self-contained application with no dependency on any external timing. If global freezing was such a problem, then we would have had significant feedback on this issue since years, and as a matter of fact, we did not. I understand that your kind of application case is more complex than Joe Average's, with likely distributed topology that justifies your proposal and makes a lot of sense in such context, but this is not the common case. Let's keep things simple for the majority, so that people don't have to fiddle with a configuration knob in the common case. An intermediate approach would be to force the threads ptimer and rtimer as blockable ones, and use a global flag to switch the rest as non-blockable, albeit this may cause non-related watchdogs to keep triggering, which most of the time could be a real pain in the neck when debugging. That' sounds better, specifically switching to a XNTIMER_BLCK logic. What about freezing the ptimer and rtimers of all xnthreads in ptraced processes? That shouldn't require us to track additional information in xntimer_t about its owner. The most effective way is to mark the timebase as enforcing blocked state for timers, have the timer handler block any timer with a blockable bit set in its status if that's the case. No need for scanning any thread list, or even to know whether any given timer is one of ptimer, rtimer or whatever. Making a timer blockable should be decided by the code that defines it, because it just knows better if any side-effect of blocking such timer may bite. Still, if we go that way, we also need to mark all timers currently created by skins as blockable (e.g. VxWorks/pSOS watchdogs and friends), so that people get the same behaviour they are used to right now. Jan -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] Optional timer freeze during ptracing
Freezing all Xenomai timers while just a single RT application is under
ptrace control can be helpful in certain debugging scenarios, but it can
as well be harmful when other parts of the systems have to continue to work.
I brought this concern up back in 2006, and I originally thought we may
address this by freezing per process. But this is far too complex for a
simple problem like this: Just make the whole thing configurable, and
keep it off by default so that -ideally- only users who are aware of the
side effects will arm it.
Gilles, you recently stumbled over such a side effect and introduced
XNTIMER_NOBLCK (for customized timer instrumentations as far as I
understood this). Do you think we still need that knob when we have
CONFIG_XENO_OPT_PTRACE_TIMER_FREEZE?
Jan
---
ksrc/nucleus/Kconfig | 14 ++
ksrc/nucleus/shadow.c | 22 --
2 files changed, 22 insertions(+), 14 deletions(-)
Index: b/ksrc/nucleus/Kconfig
===
--- a/ksrc/nucleus/Kconfig
+++ b/ksrc/nucleus/Kconfig
@@ -194,6 +194,20 @@ config XENO_OPT_DEBUG_TIMERS
This option activates debugging output for critical
timer-related operations performed by the Xenomai core.
+config XENO_OPT_PTRACE_TIMER_FREEZE
+ bool Freeze timers while debugging applications
+ depends on XENO_OPT_DEBUG
+ help
+
+ If this feature is enabled, Xenomai no longer fires timers
+ while some real-time application is being debugged via
+ ptrace (gdb etc.). This can ease stepping through real-time
+ applications as it avoids certain types of timeouts to ocure
+ due to the debugging-related delays. On the other hand, this
+ global freeze can cause unwanted side-effects to other,
+ unrelated components in the system that rely on timers
+ continue to work.
+
config XENO_OPT_WATCHDOG
bool Watchdog support
depends on XENO_OPT_DEBUG
Index: b/ksrc/nucleus/shadow.c
===
--- a/ksrc/nucleus/shadow.c
+++ b/ksrc/nucleus/shadow.c
@@ -840,18 +840,6 @@ static inline void set_linux_task_priori
prio, p-comm);
}
-static inline void lock_timers(void)
-{
- xnarch_atomic_inc(nkpod-timerlck);
- setbits(nktbase.status, XNTBLCK);
-}
-
-static inline void unlock_timers(void)
-{
- if (xnarch_atomic_dec_and_test(nkpod-timerlck))
- clrbits(nktbase.status, XNTBLCK);
-}
-
static void xnshadow_dereference_skin(unsigned magic)
{
unsigned muxid;
@@ -2199,6 +2187,7 @@ static inline void do_schedule_event(str
SIGSTOP and SIGINT in order to encompass both the NPTL and
LinuxThreads behaviours. */
+#ifdef CONFIG_XENO_OPT_PTRACE_TIMER_FREEZE
if (xnthread_test_info(threadin, XNDEBUG)) {
if (signal_pending(next)) {
sigset_t pending;
@@ -2213,10 +2202,12 @@ static inline void do_schedule_event(str
}
xnthread_clear_info(threadin, XNDEBUG);
- unlock_timers();
+ if (xnarch_atomic_dec_and_test(nkpod-timerlck))
+clrbits(nktbase.status, XNTBLCK);
}
no_ptrace:
+#endif /* CONFIG_XENO_OPT_PTRACE_TIMER_FREEZE */
if (XENO_DEBUG(NUCLEUS)) {
int sigpending = signal_pending(next);
@@ -2261,6 +2252,7 @@ static inline void do_sigwake_event(stru
xnlock_get_irqsave(nklock, s);
+#ifdef CONFIG_XENO_OPT_PTRACE_TIMER_FREEZE
if ((p-ptrace PT_PTRACED) !xnthread_test_info(thread, XNDEBUG)) {
sigset_t pending;
@@ -2271,9 +2263,11 @@ static inline void do_sigwake_event(stru
sigismember(pending, SIGSTOP)
|| sigismember(pending, SIGINT)) {
xnthread_set_info(thread, XNDEBUG);
- lock_timers();
+ xnarch_atomic_inc(nkpod-timerlck);
+ setbits(nktbase.status, XNTBLCK);
}
}
+#endif /* CONFIG_XENO_OPT_PTRACE_TIMER_FREEZE */
if (xnthread_test_state(thread, XNRELAX))
goto unlock_and_exit;
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
