GSOC [RFC]: Support for alternative tracing backends

Harsha Sharma harshasharmaiitr at
Wed Mar 21 19:50:46 UTC 2018


Greetings from my side, I'm interested in working on project "Adding
support for alternative tracing backends".
I have taken references from strace mailing list archive and other
articles. I understand the basic underlying approach about what needs
to be done, please correct me I'm getting into wrong direction.
Any suggestions will be really appreciated.

1. Add backend interface to allow for multiple alternative backends.
2. Using gdbserver:
With implementation of catch syscalls in gdbserver which adds a new
QCatchSyscalls packet to enable 'catch syscall', and newstop reasons
"syscall_entry" and "syscall_return" for those events.
GDB can catch some or all of the syscalls issued by the debuggee, and
show the related information for each syscall. If no argument is
specified, calls to and returns from all system calls will be caught.
Basic implementation idea:

strace talks to gdbserver via gdbserver backend
strace sends packet: $vCont;c  (continue)
strace receives packet:T05syscall_entry:
strace sends packet: $g (get registers)
strace receives packet: daffffffffffffff0000000000000000...

I plan to use previous patches:[1], [2], [3]

3. Using ftrace:
kprobe, uprobe and kernel tracepoint scripts make use of ftrace - This
allows tracing kernel functions, stack tracing and debugging crash.
write to files in /sys/kernel/debug/tracing and reading output from
Detailed description:  [4].

4. Perf events:
Call  perf_event_open syscalls , kernel writes events to ring buffer
in user-space, read tracepoints from ring buffer.
also act on perf_event_open() file descriptors, allowing enabling and
disabling the individual counter or event group specified by the file
descriptor argument respectively. [5]


Thanks for your time.

Best Regards,
Harsha Sharma

More information about the Strace-devel mailing list