This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug tapsets/21105] syscall testsuite failures on rawhide
- From: "mcermak at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Fri, 03 Feb 2017 16:22:51 +0000
- Subject: [Bug tapsets/21105] syscall testsuite failures on rawhide
- Auto-submitted: auto-generated
- References: <bug-21105-6586@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=21105
Martin Cermak <mcermak at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mcermak at redhat dot com
Assignee|systemtap at sourceware dot org |mcermak at redhat dot com
--- Comment #1 from Martin Cermak <mcermak at redhat dot com> ---
I'm not there yet. The [nd_]getrlimit syscall fails on fc26 because the glibc
wrapper calls prlimit64() instead of getrlimit(). So, I've tried to modify the
testcase getrlimit.c, so that it calls syscall(__NR_getrlimit, ...) directly
instead of glibc's getrlimit() wrapper, but this has a drawback:
On fc25, when syscall(__NR_getrlimit, ...) gets called in compat (-m32) mode,
kernel.function("sys_old_getrlimit") gets hit. But when glibc's getrlimit()
wrapper gets called in compat mode, kernel.function("compat_sys_getrlimit")
gets hit.
There is something weird wrt. sys_old_getrlimit(), when -1 gets passed as the
second argument to syscall(__NR_getrlimit, RLIMIT_CPU, (struct rlimit *)-1);
getrlimit(...)
------------------------------
f25 x86_64 # stap -g --poison-cache -e 'probe
kernel.function("compat_sys_getrlimit").call {printf("%s, %x\n", pp(), $rlim)}'
-c ~/a.out
kernel.function("compat_SyS_getrlimit@kernel/compat.c:490").call, ffffffff
syscall(_NR_getrlimit, ...)
------------------------------
f25 x86_64 # stap -g --poison-cache -e 'probe
kernel.function("sys_old_getrlimit").call {printf("%s, %x\n", pp(), $rlim)}' -c
~/a.out
kernel.function("SyS_old_getrlimit@kernel/sys.c:1307").call, ffffa9bb815e7ef0
Investigating...
--
You are receiving this mail because:
You are the assignee for the bug.