[Bug tapsets/12748] need syscall-number database in tapset

["mcermak at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=12748

--- Comment #1 from Martin Cermak <mcermak at redhat dot com> ---
Created attachment 9343
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9343&action=edit
syscall table tapset generator script

Attached script generates tapset file providing syscall_name() and
syscall_num() functions by parsing the strace sources.  Currently only
x86_64/i386 syscalls are supported, but extension is trivial.

However, it turns out that stap syscall names do not match their strace
counterparts exactly.  For example, all of 'stat64', 'lstat64', and 'fstat64',
known to strace, are being interpreted as 'stat' by systemtap.

Another problem is that e.g. when running the accept.c stap syscall testcase,
_stp_syscall_nr() returns value 102 for various syscalls like 'accept',
'socket', and 'bind'.  But 102 maps to 'socketcall' syscall as known to strace.
Not sure how to reasonably deal with this yet.

So, in general, it's easy to create a tapset carrying the per arch syscall
tables.  But values returned by _stp_syscall_nr() transformed to syscall names
using such tables, very often do not match systemtap syscall names as provided
by the 'name' context variable of probe syscall.

-- 
You are receiving this mail because:
You are the assignee for the bug.