* Re: [Xenomai-help] Does Valgrind work with Xenomai?
2008-11-20 13:24 ` Gilles Chanteperdrix
@ 2008-11-20 14:02 ` stephane ancelot
2008-11-20 17:05 ` Robert McCullough
1 sibling, 0 replies; 6+ messages in thread
From: stephane ancelot @ 2008-11-20 14:02 UTC (permalink / raw)
To: Gilles Chanteperdrix, rpm; +Cc: xenomai, rob
[-- Attachment #1: Type: text/plain, Size: 1925 bytes --]
wLe Thu, 20 Nov 2008 14:24:30 +0100, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> a écrit:
>
> Philippe Gerum wrote:
>> Robert McCullough wrote:
>>> Hi,
>>>
>>>
>>>
>>> I currently have a C++ application that is using 5 RTDM drivers, 2
>>> Xenomai real-time user-space threads and several non-real-time Linux
>>> threads.
>>>
>>> This application seems to have a memory leak because after running for
>>> several hours the OOM-Killer kills this application.
>>>
>>> I am looking for a memory leak detection tool to help find the leak.
>>>
>>>
>>>
>>> Two years ago in the following mail it was mentioned that making
>>> Valgrind aware of Xenomai syscalls was on the todo list.
>>>
>>> http://article.gmane.org/gmane.linux.real-time.xenomai.users/1805
>>>
>>>
>>>
>>> Has this been done?
>>>
>>
>> No news.
>>
>>> Does Valgrind work with Xenomai?
>>>
>>
>> Nope.
>
> Another way around, at least if you are using the posix skin, is to
> compile your application for Linux without Xenomai. If you are using a
> legacy API, you can do this with Xenomai/SOLO. If you are using the
> native
> API, then maybe you can ask gently Philippe to write a native skin for
> Xenomai/SOLO.
>
> Now, about valgrind, I spent some time thinking about it. A first
> modification of valgrind, is to allow dynamic syscall tables, such as
> what
> Xenomai use. This should be an easy task.
>
> The next task is to rewrite all xenomai syscalls in valgrind language
> (that is mainly to identify memory reads and writes), this is not a hard
> task, but a rather long one. So, my idea (which remains an idea for now)
> was to write the interface of the syscalls in IDL, and to generate
> automatically the code for valgrind.
>
I would tell, no , it does not ... after spending time with it .
enclosed is a patch of my work against valgrind 3.3.0
Best Regards
Steph
[-- Attachment #2: valgrind-3.3.0patch.txt --]
[-- Type: text/plain, Size: 4035 bytes --]
diff -uNr -x '*supp' -x '*html' -x '*txt' -x vg_regtest -x vg_perf -x libvex_guest_offsets.h -x genoffsets ./coregrind/m_syswrap/syswrap-linux.c ../../valgrind-3.3.0/coregrind/m_syswrap/syswrap-linux.c
--- ./coregrind/m_syswrap/syswrap-linux.c 2007-12-11 00:18:43.000000000 +0100
+++ ../../valgrind-3.3.0/coregrind/m_syswrap/syswrap-linux.c 2008-05-21 14:55:59.338660493 +0200
@@ -2797,6 +2797,7 @@
}
}
+
/* ---------------------------------------------------------------------
ioprio_ wrappers
------------------------------------------------------------------ */
@@ -2822,6 +2823,9 @@
PRE_MEM_READ( "utimensat(tvp)", ARG3, sizeof(struct vki_timespec) );
}
+
+
+
#undef PRE
#undef POST
diff -uNr -x '*supp' -x '*html' -x '*txt' -x vg_regtest -x vg_perf -x libvex_guest_offsets.h -x genoffsets ./coregrind/m_syswrap/syswrap-x86-linux.c ../../valgrind-3.3.0/coregrind/m_syswrap/syswrap-x86-linux.c
--- ./coregrind/m_syswrap/syswrap-x86-linux.c 2007-12-11 00:18:43.000000000 +0100
+++ ../../valgrind-3.3.0/coregrind/m_syswrap/syswrap-x86-linux.c 2008-05-21 15:44:59.578280281 +0200
@@ -788,6 +788,8 @@
DECL_TEMPLATE(x86_linux, sys_vm86old);
DECL_TEMPLATE(x86_linux, sys_vm86);
DECL_TEMPLATE(x86_linux, sys_syscall223);
+DECL_TEMPLATE(x86_linux, xeno_bind_skin);
+DECL_TEMPLATE(x86_linux, xn_shadow_sys_info);
PRE(old_select)
{
@@ -1816,6 +1818,26 @@
ARG4, ARG5, ARG6 );
}
+PRE(xeno_bind_skin)
+{
+ PRINT("skin pre");
+}
+
+POST(xeno_bind_skin)
+{
+ PRINT("rt_skin_bind pre");
+}
+PRE(xn_shadow_sys_info)
+{
+ PRINT("xn_shadow_sys_info");
+}
+
+POST(xn_shadow_sys_info)
+{
+ PRINT("xn_shadow_sys_info");
+}
+
+
#undef PRE
#undef POST
@@ -1827,8 +1849,18 @@
/* Add an x86-linux specific wrapper to a syscall table. */
#define PLAX_(sysno, name) WRAPPER_ENTRY_X_(x86_linux, sysno, name)
#define PLAXY(sysno, name) WRAPPER_ENTRY_XY(x86_linux, sysno, name)
-
-
+/* Xenomai multiplexer syscall. */
+#define __xn_sys_mux 555 /* Must fit within 15bit */
+/* Xenomai nucleus syscalls. */
+#define __xn_sys_bind 0 /* muxid = bind_to_interface(magic,featdep,abirev) */
+#define __xn_sys_completion 1 /* xnshadow_completion(&completion) */
+#define __xn_sys_migrate 2 /* switched = xnshadow_relax/harden() */
+#define __xn_sys_barrier 3 /* started = xnshadow_wait_barrier(&entry,&cookie) */
+#define __xn_sys_info 4 /* xnshadow_get_info(muxid,&info) */
+#define __xn_sys_arch 5 /* r = xnarch_local_syscall(args) */
+#define __xn_sys_trace 6 /* r = xntrace_xxx(...) */
+#define __xn_mux_code(shifted_id,op) ((op << 24)|shifted_id|(__xn_sys_mux & 0x7fff))
+#define XENOMAI_SYSCALL(op) __xn_mux_code(0,op)
// This table maps from __NR_xxx syscall numbers (from
// linux/include/asm-i386/unistd.h) to the appropriate PRE/POST sys_foo()
// wrappers on x86 (as per sys_call_table in linux/arch/i386/kernel/entry.S).
@@ -2218,6 +2250,9 @@
LINXY(__NR_get_robust_list, sys_get_robust_list), // 312
LINX_(__NR_utimensat, sys_utimensat), // 320
+// LINXY(__xn_sys_mux, rt_heap_bind), // 555
+ PLAXY(__xn_sys_mux, xeno_bind_skin), // 555
+ PLAXY(XENOMAI_SYSCALL(__xn_sys_info),xn_shadow_sys_info),
};
const UInt ML_(syscall_table_size) =
diff -uNr -x '*supp' -x '*html' -x '*txt' -x vg_regtest -x vg_perf -x libvex_guest_offsets.h -x genoffsets ./include/vki/vki-scnums-x86-linux.h ../../valgrind-3.3.0/include/vki/vki-scnums-x86-linux.h
--- ./include/vki/vki-scnums-x86-linux.h 2007-12-11 00:18:25.000000000 +0100
+++ ../../valgrind-3.3.0/include/vki/vki-scnums-x86-linux.h 2008-05-16 16:15:34.286985343 +0200
@@ -353,6 +353,8 @@
#define __NR_vmsplice 316
#define __NR_utimensat 320
+#define __xn_sys_mux 555
+
#endif /* __VKI_SCNUMS_X86_LINUX_H */
/*--------------------------------------------------------------------*/
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [Xenomai-help] Does Valgrind work with Xenomai?
2008-11-20 13:24 ` Gilles Chanteperdrix
2008-11-20 14:02 ` stephane ancelot
@ 2008-11-20 17:05 ` Robert McCullough
2008-11-20 17:12 ` Gilles Chanteperdrix
1 sibling, 1 reply; 6+ messages in thread
From: Robert McCullough @ 2008-11-20 17:05 UTC (permalink / raw)
To: 'Gilles Chanteperdrix', rpm; +Cc: xenomai
--> -----Original Message-----
--> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
--> Sent: Thursday, November 20, 2008 8:25 AM
--> To: rpm@xenomai.org
--> Cc: rob@domain.hid; xenomai@xenomai.org
--> Subject: Re: [Xenomai-help] Does Valgrind work with Xenomai?
-->
-->
--> Philippe Gerum wrote:
--> > Robert McCullough wrote:
--> >> Hi,
--> >>
--> >>
--> >>
--> >> I currently have a C++ application that is using 5 RTDM drivers, 2
--> >> Xenomai real-time user-space threads and several non-real-time
--> Linux
--> >> threads.
--> >>
--> >> This application seems to have a memory leak because after running
--> for
--> >> several hours the OOM-Killer kills this application.
--> >>
--> >> I am looking for a memory leak detection tool to help find the
--> leak.
--> >>
--> >>
--> >>
--> >> Two years ago in the following mail it was mentioned that making
--> >> Valgrind aware of Xenomai syscalls was on the todo list.
--> >>
--> >> http://article.gmane.org/gmane.linux.real-time.xenomai.users/1805
--> >>
--> >>
--> >>
--> >> Has this been done?
--> >>
--> >
--> > No news.
--> >
--> >> Does Valgrind work with Xenomai?
--> >>
--> >
--> > Nope.
-->
--> Another way around, at least if you are using the posix skin, is to
--> compile your application for Linux without Xenomai. If you are using a
--> legacy API, you can do this with Xenomai/SOLO. If you are using the
--> native
--> API, then maybe you can ask gently Philippe to write a native skin for
--> Xenomai/SOLO.
-->
--> Now, about valgrind, I spent some time thinking about it. A first
--> modification of valgrind, is to allow dynamic syscall tables, such as
--> what
--> Xenomai use. This should be an easy task.
-->
--> The next task is to rewrite all xenomai syscalls in valgrind language
--> (that is mainly to identify memory reads and writes), this is not a
--> hard
--> task, but a rather long one. So, my idea (which remains an idea for
--> now)
--> was to write the interface of the syscalls in IDL, and to generate
--> automatically the code for valgrind.
-->
--> --
--> Gilles.
[Robert McCullough]
Thanks Gilles for your advice and information.
My application uses the native skin but not to much so it might not take too
much to convert to the posix skin. I will look into doing this. As far as
the 5 RTDM drivers go, they will not run under Linux without Xenomai,
correct? So, I will have to replace them with non-real-time drivers or
simulate them in my application.
I am new to valgrind and have just started to try it. So, at this time I
would not be very much help in the modification to work with Xenomai.
I am currently using the Linux "top" utility to monitor the memory usage of
my application. Is this the best utility for this job?
Also, is there a way to monitor the memory usage of my Xenomai tasks and
RTDM drivers?
Best regards,
Robert McCullough
^ permalink raw reply [flat|nested] 6+ messages in thread