This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug tapsets/15690] New: syscall.rt_sigprocmask probe alias broken on s390x/ppc64 for 32-bit apps
- From: "dsmith at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Thu, 27 Jun 2013 15:45:13 +0000
- Subject: [Bug tapsets/15690] New: syscall.rt_sigprocmask probe alias broken on s390x/ppc64 for 32-bit apps
- Auto-submitted: auto-generated
http://sourceware.org/bugzilla/show_bug.cgi?id=15690
Bug ID: 15690
Summary: syscall.rt_sigprocmask probe alias broken on
s390x/ppc64 for 32-bit apps
Product: systemtap
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: tapsets
Assignee: systemtap at sourceware dot org
Reporter: dsmith at redhat dot com
On s390x/ppc64, the syscall.rt_sigprocmask probe alias is broken when probing
32-bit apps, always displaying '[EMPTY]' for the sigset value.
Here's the definition of syscall.rt_sigprocmask from
tapset/linux/syscalls2.stp:
====
# rt_sigprocmask _____________________________________________
# long sys32_rt_sigprocmask(u32 how, compat_sigset_t __user *set,
compat_sigset_t __user *oset, size_t sigsetsize)
# long compat_sys_rt_sigprocmask(int how, compat_sigset_t __user *set,
compat_sigset_t __user *oset, compat_size_t sigsetsize)
# long sys_rt_sigprocmask(int how, sigset_t __user *set, sigset_t __user *oset,
size_t sigsetsize)
#
probe syscall.rt_sigprocmask = kernel.function("sys32_rt_sigprocmask").call ?,
kernel.function("compat_sys_rt_sigprocmask").call ?,
kernel.function("sys_rt_sigprocmask").call ?
{
name = "rt_sigprocmask"
how = $how
how_str = _sigprocmask_how_str($how)
set_uaddr = @choose_defined($set, $nset)
oldset_uaddr = $oset
argstr = sprintf("%s, [%s], %p, %d", how_str, _stp_sigset_u(set_uaddr),
$oset, $sigsetsize)
}
====
The problem is that the 'compat' entry points (compat_sys_rt_sigprocmask and
sys_rt_sigprocmask) don't get a 'sigset_t', they get a 'compat_sigset_t'. On
x86_64, a 'compat_sigset_t' is laid out similarly to a 'sigset_t'. On
big-endian platforms like ppc64 and s390x, a 'compat_sigset_t' is laid out
differently than a 'sigset_t'. Since _stp_sigset_u() isn't expecting a
'compat_sigset_t', it doesn't handle it correctly.
--
You are receiving this mail because:
You are the assignee for the bug.