LTTng » LTTng-modules

Tested under lttng-modules-2.3.0-1-78c8710, but lttng-syscalls-generate-headers.sh hasn't changed as of 2.4.0-1-fb2c377 so this is still a problem.

I followed the steps to regenerate the system call names for kernel 3.9.3 and ran into several problems with lttng-syscalls-generate-headers.sh.

The resulting x86-64-syscalls-3.9.3_integers.h begins with:

/* THIS FILE IS AUTO-GENERATED. DO NOT EDIT */
#ifndef CREATE_SYSCALL_TABLE

#if !defined(_TRACE_SYSCALLS_INTEGERS_H) || defined(TRACE_HEADER_MULTI_READ)
#define _TRACE_SYSCALLS_INTEGERS_H

#include <linux/tracepoint.h>
#include <linux/syscalls.h>
#include "x86-64-syscalls-3.9.3_integers_override.h" 
#include "syscalls_integers_override.h" 

SC_DECLARE_EVENT_CLASS_NOARGS(syscalls_noargs,
    TP_STRUCT__entry(),
    TP_fast_assign(),
    TP_printk()
)#ifndef OVERRIDE_64_sys_sched_yield
SC_DEFINE_EVENT_NOARGS(syscalls_noargs, sys_sched_yield)
#endif
[...]

Notice the missing new-line at the end of the SC_DECLARE_EVENT_CLASS_NOARGS macro.

Also, running lttng-syscalls-generate-headers.sh with the arguments 'integers' and then 'pointers' as instructed did not generate x86-64-syscalls-3.9.3_integers_override.h nor x86-64-syscalls-3.9.3_pointers_override.h, so the #include appearing above will fail. Running lttng-syscalls-generate-headers.sh with an 'integer_override' argument is clearly not the solution.

Another problem lies at the end of the generated integers header:

[...]
#endif
SUCCESS

#endif /* CREATE_SYSCALL_TABLE */

The dmesg 'SUCCESS' should have been filtered out, methinks. Oddly, pointers doesn't have this extra line.

Looking into the lttng-syscalls-generate-headers.sh code, I spotted this problem:

[...]
# Macro for tracing syscall table

rm -f ${TMPFILE}
for NRARGS in $(seq 0 6); do
    grep "^syscall [^ ]* nr [^ ]* nbargs ${NRARGS} " ${SRCFILE} >> ${TMPFILE}
done

echo \
" 
#endif /*  _TRACE_SYSCALLS_${CLASSCAP}_H */
[...]
#include \"syscalls_${CLASS}_override.h\" 
" >> ${HEADER}

NRARGS=0

if [ "$CLASS" = integers ]; then
#noargs
grep "^syscall [^ ]* nr [^ ]* nbargs ${NRARGS} " ${SRCFILE} > ${TMPFILE}
perl -p -e 's/^syscall ([^ ]*) nr ([^ ]*) nbargs ([^ ]*) .*$/'\
'#ifndef OVERRIDE_TABLE_'"${BITNESS}"'_sys_$1\n'\
'TRACE_SYSCALL_TABLE\(syscalls_noargs, sys_$1, $2, $3\)\n'\
'#endif/g'\
    ${TMPFILE} >> ${HEADER}
fi

#others.
grep -v "^syscall [^ ]* nr [^ ]* nbargs ${NRARGS} " ${SRCFILE} > ${TMPFILE}
perl -p -e 's/^syscall ([^ ]*) nr ([^ ]*) nbargs ([^ ]*) .*$/'\
'#ifndef OVERRIDE_TABLE_'"${BITNESS}"'_sys_$1\n'\
'TRACE_SYSCALL_TABLE(sys_$1, sys_$1, $2, $3)\n'\
'#endif/g'\
    ${TMPFILE} >> ${HEADER}
[...]

Clearly, the ${TMPFILE} generated by the for NRARGS in $(seq 0 6); do loop will be overwritten by the next two blocks of instructions, without being used. Either it is indeed useless and the loop should be removed from the script, or it is not, and the script was supposed to write something from it into the ${HEADER}.

These problems aside, the script is not user-friendly at all: it gives no feedback whatsoever and makes no attempt to validate its input parameters. For instance, you can pass it 'integer' instead of 'integers' and it won't complain (the $? value is 0), generating an effectively empty header.

The script should really validate the number of arguments received (it expects four, no more, no less) and their values: the first should be either integers or pointers (any other value is an error), the second should be a working directory (-d and -w tests) and not end with a trailing slash (${INPUTDIR%/}), the third a filename in that directory (-f and -r tests) and the fourth either 32 or 64 (any other value is an error). Correct termination should be reported to the user by a simple message such as 'Header ${HEADER} created.'

Ideally, instrumentation/syscalls/README should also be less laconic. A simple recommended procedure could be to edit instrumentation/syscalls/headers/syscalls_integers.h and syscalls_pointers.h to switch the appropriate architecture (e.g. CONFIG_X86_64) to the newly-generated headers (e.g. changing the current x86-64-syscalls-3.10.0-rc7_<CLASS>.h into x86-64-syscalls-3.13.7_<CLASS>.h), then rebuild lttng-modules.