* Jan Glauber (jan.glau...@gmail.com) wrote: > On Wed, Apr 10, 2013 at 12:20:12PM -0400, Mathieu Desnoyers wrote: > > > > Thanks for the detailed report !! > > > > Please try with this commit: > > Yes, that patch works. But I'm still curious if you can explain what the > override was for ;-
The "override" allows defining how to serialize the information for specific system calls. It can either replace the behavior of the "semi-automated" description of the system call (brought into lttng-modules by means of the system call extractor script), or just provide the serialization description for a system call that was not available to the system call extractor. In this case, sys_set_tls was not available for automated extraction, so the override entry has been added to it would not appear as a "sys_unknown" system call, but would rather show "sys_set_tls" along with the well-printed system call arguments. You may want to have a look at: lttng-modules/instrumentation/syscalls/README for details. If we want to handle the set_tls special-case (and same for other ARM-specific syscalls), we'll probably want to do that with a arm-specific table that will contain those system calls. Thanks, Mathieu > > --Jan > > > commit 11fa478f18241fedee86f7dc7820a91c629c9e7e > > Author: Mathieu Desnoyers <mathieu.desnoy...@efficios.com> > > Date: Wed Apr 10 12:14:38 2013 -0400 > > > > Fix: remove ARM set_tls system call override > > > > We'll need to find a better way to instrument ARM-specific system calls > > located at a far offset from the standard systems calls. A 16MB > > lttng-modules kernel module is really not acceptable. > > > > Removing this instrumentation for now. sys_set_tls will appear as > > sys_unknown. > > > > Fixes #472 > > > > CC: Ryan Kyser <ryan.ky...@jci.com> > > Ref: http://lists.lttng.org/pipermail/lttng-dev/2013-April/019990.html > > Signed-off-by: Mathieu Desnoyers <mathieu.desnoy...@efficios.com> > > > > diff --git > > a/instrumentation/syscalls/headers/arm-32-syscalls-2.6.38_integers_override.h > > > > b/instrumentation/syscalls/headers/arm-32-syscalls-2.6.38_integers_override.h > > index 93b8674..895370f 100644 > > --- > > a/instrumentation/syscalls/headers/arm-32-syscalls-2.6.38_integers_override.h > > +++ > > b/instrumentation/syscalls/headers/arm-32-syscalls-2.6.38_integers_override.h > > @@ -2,7 +2,6 @@ > > > > #define OVERRIDE_TABLE_32_sys_arm_fadvise64_64 > > #define OVERRIDE_TABLE_32_sys_sync_file_range2 > > -#define OVERRIDE_TABLE_32_sys_set_tls > > > > #ifndef CREATE_SYSCALL_TABLE > > > > @@ -38,18 +37,6 @@ SC_TRACE_EVENT(sys_sync_file_range2, > > TP_printk() > > ) > > > > -SC_TRACE_EVENT(sys_set_tls, > > - TP_PROTO(unsigned int tid, unsigned long tls), > > - TP_ARGS(tid, tls), > > - TP_STRUCT__entry( > > - __field(unsigned int, tid) > > - __field_hex(unsigned int, tls)), > > - TP_fast_assign( > > - tp_assign(tid, tid) > > - tp_assign(tls, tls)), > > - TP_printk() > > -) > > - > > #else /* CREATE_SYSCALL_TABLE */ > > > > #define OVVERRIDE_TABLE_32_sys_mmap > > @@ -59,9 +46,6 @@ TRACE_SYSCALL_TABLE(sys_mmap, sys_mmap, 90, 6) > > TRACE_SYSCALL_TABLE(sys_arm_fadvise64_64, sys_arm_fadvise64_64, 270, 4) > > #define OVERRIDE_TABLE_32_sys_sync_file_range2 > > TRACE_SYSCALL_TABLE(sys_sync_file_range2, sys_sync_file_range2, 341, 4) > > -#define OVERRIDE_TABLE_32_sys_set_tls > > -TRACE_SYSCALL_TABLE(sys_set_tls, sys_set_tls, 0xf0005, 2) > > - > > > > #endif /* CREATE_SYSCALL_TABLE */ > > > > > > > > > > > > --Jan > > > > > > > -PL > > > > > > > > > > > > > > > > On Wed, Apr 10, 2013 at 9:02 AM, Jan Glauber <jan.glau...@gmail.com> > > > > wrote: > > > > > > > > > On Wed, Apr 10, 2013 at 08:37:18AM -0400, PLSTC wrote: > > > > > > Hey Jan, > > > > > > > > > > > > I cannot speak on behalf of everyone here, but during our attempt > > > > > > to port > > > > > > LTTng to Android, we also noticed that the kernels we were using > > > > > > (3.0.x) > > > > > > were nowhere near the requirements for syscall tracepoints support. > > > > > > I > > > > > > believe such support was added on x86/64 way earlier (early 3.x) > > > > > > than on > > > > > > ARM, which is why it was included in LTTng's modules a while ago. > > > > > > Simply > > > > > > put, the ARM kernel is late. > > > > > > > > > > OK, so for ARM kernel version 3.6 is the minimum unless the syscall > > > > > tracepoint > > > > > support is backported. > > > > > > > > > > > There are a few actuals ways to 'enable' syscall tracepoints > > > > > > support on > > > > > > early ARM kernels, but they all including a bit of kernel > > > > > hacking/patching. > > > > > > I could send you some links if you're interested in that. > > > > > > > > > > Yes, sure! > > > > > > > > > > --Jan > > > > > > > > > > > -PL > > > > > > On Apr 10, 2013 4:40 AM, "Jan Glauber" <jan.glau...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I want to use LTTng for system call tracing on ARM. Now > > > > > > > lttng-modules > > > > > seems > > > > > > > to support system call tracing on ARM already since > > > > > > > "8f4f80e LTTng Modules ARM syscall instrumentation". > > > > > > > > > > > > > > But I wonder how that worked since lttng-syscalls.c is only build > > > > > > > under > > > > > > > CONFIG_HAVE_SYSCALL_TRACEPOINTS and that was added to ARM only > > > > > > > with > > > > > kernel > > > > > > > 3.6 > > > > > > > (much after than the lttng-modules commit). > > > > > > > > > > > > > > Am I missing something? Is system call tracing working on ARM > > > > > > > with the > > > > > > > upstream > > > > > > > LTTng version? > > > > > > > > > > > > > > thanks, > > > > > > > Jan > > > > > > > > > > > > > > _______________________________________________ > > > > > > > lttng-dev mailing list > > > > > > > lttng-dev@lists.lttng.org > > > > > > > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev > > > > > > > > > > > > > > > > > > _______________________________________________ > > > lttng-dev mailing list > > > lttng-dev@lists.lttng.org > > > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev > > > > -- > > Mathieu Desnoyers > > EfficiOS Inc. > > http://www.efficios.com -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev