Module: xenomai-forge
Branch: master
Commit: 65a9418f245c2138aa1bfb2d69975da3dbb6b0bd

Author: Philippe Gerum <>
Date:   Fri Jul 12 15:41:13 2013 +0200

slackspot: provide README with basic usage


 utils/slackspot/README |   84 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 84 insertions(+), 0 deletions(-)

diff --git a/utils/slackspot/README b/utils/slackspot/README
new file mode 100644
index 0000000..f1e94c8
--- /dev/null
+++ b/utils/slackspot/README
@@ -0,0 +1,84 @@
+We desperately needed a way to help spotting code locations causing
+spurious relaxes of real-time threads, at source level.
+Combining SIGXCPU receipts and the backtrace() utility directly from
+the application code used to be the recommended way of doing this, but
+this fell short of being really handy, simply because that debug
+feature had to be implemented in an ad hoc manner within each new
+With the advent of the copperplate library, with most RTOS APIs moving
+to user-space on top of the POSIX skin, we really want a better, more
+efficient approach to debug those issues over the Cobalt core, and we
+want it available for any application in a snap, implemented once for
+The approach chosen combines dedicated kernel support exporting trace
+information about spurious relaxes through the debug/relax vfile, and
+a userland utility called "slackspot", which parses the vfile output
+to display the program backtrace, so that we can locate the offending
+code easily.
+The motivation to centralize tracing information about relaxes
+directly into kernel space is fourfold:
+- it allows to gather all the trace data into a single location and
+keep it safe there, with no external log file involved.
+- enabling the tracing does not impose any requirement on the
+application (aside of being compiled with debug symbols for best
+interpreting that information). We only need a kernel config switch
+- the data is collected and can be made available exactly the same
+way regardless of the application emitting the relax requests, or
+whether it is still alive when the trace data are displayed.
+- the kernel is able to provide accurate and detailed trace
+information, such as the relative offset of instructions causing relax
+requests within dynamic shared objects, without having to guess it
+roughly from /proc/pid/maps, or relying on ldd's --function-relocs
+feature, which both require to run on the target system to get the
+needed information. Instead, we allow a build host to use a
+cross-compilation toolchain later to extract the source location, from
+the raw data the kernel has provided on the target system.
+Here is a typical debugging session, involving a target board running
+the Xenomai application, and a host system, providing the
+cross-compilation toolchain used to build that application. We use the
+netcat utility to pull the trace data over the wire from the target,
+and process it locally on our debug host:
+target> netcat -l -p <port> -c < /proc/xenomai/debug/relax
+host> nc <target-ip> <port> | CROSS_COMPILE=ppc_6xx- ./slackspot 
--path=/opt/rootfs/MPC5200/lib:$HOME/frags/relax --filter thread=Task*
+Thread[828] "Task 2" started by /relax:
+   #0  0xfff00000 ???
+   #1  0x000001bb ???
+   #2  0x00064393 _IO_file_doallocate() in ??:?
+   #3  0x00073d6f _IO_doallocbuf() in ??:?
+   #4  0x00072d87 _IO_file_overflow() in ??:?
+   #5  0x00075f83 __overflow() in ??:?
+   #6  0x0006997b putchar() in ??:?
+   #7  0x100017db task2_func() in /home/rpm/frags/relax/relax.c:23
+   #8  0x000078d7 rt_task_trampoline() in 
+   #9  0x00005a6b start_thread() in pthread_create.c:?
+   #10 0x000d389f __clone() in ??:?
+Thread[828] "Task 2" started by /relax (4 times):
+   #0  0x000c443f write() in ??:?
+   #1  0x00072553 _IO_file_write() in ??:?
+   #2  0x000721cf _IO_file_seek() in ??:?
+   #3  0x000724c7 _IO_do_write() in ??:?
+   #4  0x00072c2f _IO_file_sync() in ??:?
+   #5  0x00064a4f _IO_fflush() in ??:?
+   #6  0x100017eb task2_func() in /home/rpm/frags/relax/relax.c:24
+   #7  0x000078d7 rt_task_trampoline() in 
+   #8  0x00005a6b start_thread() in pthread_create.c:?
+   #9  0x000d389f __clone() in ??:?
+Looks like someone is doing silly things both at lines 23 and 24 from
+relax.c. Isn't this nice?

Xenomai-git mailing list

Reply via email to