[ltt-dev] LTTng Statedump Code

[Mathieu Desnoyers]

Hi Jan,

* Jan Blunck (jblunck at suse.de) wrote:
> I have a question about the current LTTng code. I'm currently reviewing the
> code and found things like:
> 
> void ltt_dump_sys_call_table(void *call_data)
> {
>        int i;
>        char namebuf[KSYM_NAME_LEN];
> 
>        for (i = 0; i < __NR_syscall_max + 1; i++) {
>                sprint_symbol(namebuf, (unsigned long)sys_call_table[i]);
>                __trace_mark(0, statedump_sys_call_table, call_data,
>                        "id %d address %p symbol %s",
>                        i, (void*)sys_call_table[i], namebuf);
>        }
> }
> EXPORT_SYMBOL_GPL(ltt_dump_sys_call_table);
> 
> This is really confusing. Why do you actually need this? The syscall table
> isn't changing that often during runtime. Besides that this is only
> implemented for arch/x86.
> 

The implementation for other arches is pending. It's actually needed to
get the mapping between system call ID and the symbol of the syscall
function, so we have a meaningful name to show in the analysis tool.

> For what purpose do you need this statedump code in the first place? Doesn't
> the /proc interface provide (more than) enough data for you?
> 

1 - /proc is broken. See the sorted seq proc file patches I have in my
lttng tree for details. Basically, it offers no locking of the data
structures between repeated /proc reads which should actually output the
same data. Therefore, complete lines could be missing (and not lines
that happen to correspond to the element being removed from the
structure). Therefore, using /proc for the overall kernel statedump
would be flaky.

2 - There are cases where the trace goes directly to a serial port
without ever touching userspace. LTTng offers the ability to register a
different transport which will export the data possibly without touching
userspace. Therefore, I did not want to rely on userspace to export that
kind of information.

However, in the specific case of syscalls, they are available
statically. We could copy the vmlinux image with the trace and require
that it should be there so we can do all sorts of symbol lookup.  Then
then becomes a packaging/using the right libs issue. On the plus side,
we could automatically lookup any function pointer. I would be open to
merge patches to LTTV and ltt-control that do this.

Mathieu


> Regards,
> 	Jan
> 
> -- 
> Jan Blunck <jblunck at suse.de>

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68