This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug tapsets/15219] syscall.exp failures on RHEL5, RHEL6, and rawhide
- From: "dsmith at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Tue, 11 Jun 2013 14:37:38 +0000
- Subject: [Bug tapsets/15219] syscall.exp failures on RHEL5, RHEL6, and rawhide
- Auto-submitted: auto-generated
- References: <bug-15219-6586 at http dot sourceware dot org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=15219
--- Comment #7 from David Smith <dsmith at redhat dot com> ---
Created attachment 7067
--> http://sourceware.org/bugzilla/attachment.cgi?id=7067&action=edit
anti-nested syscall patch
Here's a new patch that attempts (and fails) to fix this problem a different
way.
Instead of changing the way we access memory, instead this patch tries to avoid
the nested system calls. To do this, in the 64-bit syscall .call and .return
probe, I added the following line:
if (%{ _stp_is_compat_task() %}) next
So, if we're in a 64-bit syscall with a 32-bit process, skip the probe (and let
the 32-bit syscall handle it). (That line could be prettied up by using a
macro.)
As I mentioned above, the advantage this approach has is that it doesn't change
the way we access memory. The disadvantages are:
- Knowing when and where to add that line. The problem is that some 32-bit
syscalls are wrappers around the 64-bit syscall, and some 32-bit syscalls call
the same underlying function that the 64-bit syscall does (after massaging the
arguments a bit). So, in the 1st case (the wrapper case), we need the probe
skip line, but in the 2nd case we don't. I used the syscall.exp test case to
know where to put that line when developing the patch, but the syscall.exp test
case doesn't test every system call.
- Whether we need that line or not can change with kernels. For example, the
syscall.rt_sigprocmask probe should be skipped on RHEL[56] kernels, but not on
rawhide.
So, some more work will be required here.
--
You are receiving this mail because:
You are the assignee for the bug.