[lttng-dev] LTTng system call tracing on ARM
Mathieu Desnoyers
mathieu.desnoyers at efficios.com
Thu Apr 11 09:20:30 EDT 2013
* Jan Glauber (jan.glauber at gmail.com) wrote:
> On Wed, Apr 10, 2013 at 12:39:50PM -0400, Mathieu Desnoyers wrote:
> > * Jan Glauber (jan.glauber at 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.
>
> OK, thanks for explaining. So the version in instrumentation/syscalls/headers
> doesn't mean much, its just the starting point from where the extractor
> script picked up the descriptions.
>
> So we could append recent system calls without generating new headers for
> lets say 3.4.
Yes, this is one option.
The other option, if we want to upgrade a system call table from e.g.
2.6.38 to 3.4, is to just replace the automatically generated header by
headers generated by extracting system calls from a 3.4 kernel. This
will keep the overrides in places, because they are located into a
separate override file.
Therefore, all work done by hand in addition to the automatically
generated file does not get wasted between updates.
>
> > 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.
>
> Yes, a seperate table would solve the issue. I don't know if ARM is the
> only arch doing such tricks to the system call table, so it might be worth
> checkingt that.
Indeed. This would probably be 2.3 material. I'm happy with showing
set_tls as sys_unknown for the moment.
Thanks!
Mathieu
>
> Thanks,
> Jan
>
> > Thanks,
> >
> > Mathieu
> >
> >
> > >
> > > --Jan
> > >
> > > > commit 11fa478f18241fedee86f7dc7820a91c629c9e7e
> > > > Author: Mathieu Desnoyers <mathieu.desnoyers at 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.Kyser at jci.com>
> > > > Ref: http://lists.lttng.org/pipermail/lttng-dev/2013-April/019990.html
> > > > Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers at 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.glauber at 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.glauber at 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 at lists.lttng.org
> > > > > > > > > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> > > > > > > > >
> > > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > lttng-dev mailing list
> > > > > lttng-dev at 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
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
More information about the lttng-dev
mailing list