public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: "mcermak at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: systemtap@sourceware.org
Subject: [Bug tapsets/17714] New: poll.c syscall testcase
Date: Mon, 15 Dec 2014 11:44:00 -0000	[thread overview]
Message-ID: <bug-17714-6586@http.sourceware.org/bugzilla/> (raw)

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

            Bug ID: 17714
           Summary: poll.c syscall testcase
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tapsets
          Assignee: systemtap at sourceware dot org
          Reporter: mcermak at redhat dot com

Created attachment 8015
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8015&action=edit
proposed patch

Two issues wrt. syscall.epoll_pwait and related testcase:


1) in the syscalls.stp tapset, $events and $sigmask pointers from
syscall.epoll_pwait have wrong values on s390 31-on-64. Following update fixes
the issue for me and seems to test fine "everywhere".

=======
--- a/tapset/linux/syscalls.stp
+++ b/tapset/linux/syscalls.stp
@@ -857,14 +857,14 @@ probe syscall.epoll_pwait =
kernel.function("compat_sys_epoll_pwait").call ?,
 {
        name = "epoll_pwait"
        epfd = __int32($epfd)
-       events_uaddr = $events
+       events_uaddr = @__pointer($events)
        maxevents = __int32($maxevents)
        timeout = __int32($timeout)
-       sigmask_uaddr = $sigmask
+       sigmask_uaddr = @__pointer($sigmask)
        sigsetsize = $sigsetsize
        argstr = sprintf("%d, %p, %d, %d, %p, %d",
-                        __int32($epfd), $events, __int32($maxevents),
-                        __int32($timeout), $sigmask, $sigsetsize)
+                        __int32($epfd), events_uaddr, __int32($maxevents),
+                        __int32($timeout), sigmask_uaddr, $sigsetsize)
 }
=======



2) Second problem is that on el5 x86_64, epoll_pwait() is not available, but
SYS_epoll_pwait is defined. This is unlike other el5 arches, where
SYS_epoll_pwait is not defined. This causes link time error and skipping the
test on the platform in question. Using following wrapper works the issue
around for me and seems to test fine "everywhere":

=======
#ifdef SYS_epoll_pwait                                                          
int __epoll_pwait(int epfd, struct epoll_event *events,                         
                  int maxevents, int timeout,                                   
                  const sigset_t *set)                                          
{                                                                               
    return syscall(__NR_epoll_pwait, epfd, events, maxevents, timeout,          
                   set, _NSIG / 8);                                             
}                                                                               
#endif
=======

Related testcases are then being updated like this:

=======
#ifdef SYS_epoll_pwait                                                          
  __epoll_pwait(fd, events, 17, 0, NULL);                                       
  //staptest// [[[[epoll_pwait (NNNN, XXXX, 17, 0, 0x0, NNNN) = 0!!!!ni_syscall
() = -38 (ENOSYS)]]]]

  __epoll_pwait(fd, events, 17, 0, &sigs);                                      
  //staptest// [[[[epoll_pwait (NNNN, XXXX, 17, 0, XXXX, NNNN) =
0!!!!ni_syscall () = -38 (ENOSYS)]]]]

... stuff deleted ...

#endif
=======

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

             reply	other threads:[~2014-12-15 11:44 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-15 11:44 mcermak at redhat dot com [this message]
2015-01-12 16:49 ` [Bug tapsets/17714] " mcermak at redhat dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-17714-6586@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=systemtap@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).