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

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

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

David Smith <dsmith at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dsmith at redhat dot com

--- Comment #3 from David Smith <dsmith at redhat dot com> ---
(In reply to Martin Cermak from comment #1)
> Created attachment 9343 [details]
> 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.

That's by design. The user always calls "stat", "lstat", or "fstat" -
underneath glibc will call either stat/stat64 based on whether a couple of
defines are defined. If the following are defined, glibc will call the 64-bit
versions:

#define _LARGEFILE64_SOURCE
#define _FILE_OFFSET_BITS 64

(BTW, some platforms also have newfstat/newfstatat/newlstat/newstat.)

systemtap tries to report things from the user's point of view, so if we get a
stat/stat64/newstat syscall, it reports all of them just as "stat".

> 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.

I'm not sure you can without looking at the args. What is going on there is
that on some platforms
connect/getpeername/getsockname/getsockopt/listen/recv/recvfrom/recvmsg/send/sendmsg/sendto/setsockopt/shutdown/socket/socketpair
can either be individual syscalls or some/all of them can use socketcall as a
common kernel entry point.

Once again systemtap tries to report what the user actually called, not what
kernel entry point got used.

> 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.

I think we're just going to have to live with them not matching sometimes.

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