From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 100229 invoked by alias); 20 Jun 2016 18:07:15 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 100118 invoked by uid 48); 20 Jun 2016 18:07:01 -0000 From: "dsmith at redhat dot com" To: systemtap@sourceware.org Subject: [Bug tapsets/12748] need syscall-number database in tapset Date: Mon, 20 Jun 2016 18:07:00 -0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: systemtap X-Bugzilla-Component: tapsets X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dsmith at redhat dot com X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: systemtap at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2016-q2/txt/msg00254.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D12748 David Smith changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dsmith at redhat dot com --- Comment #3 from David Smith --- (In reply to Martin Cermak from comment #1) > Created attachment 9343 [details] > syscall table tapset generator script >=20 > 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. >=20 > 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-b= it 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 ge= t 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/sen= d/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. --=20 You are receiving this mail because: You are the assignee for the bug.