This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tapsets/21105] syscall testsuite failures on rawhide


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]