[Bug tapsets/11263] exposing foo32 syscalls

["dsmith at redhat dot com" <sourceware-bugzilla@sourceware.org>]

------- Additional Comments From dsmith at redhat dot com  2010-02-09 19:02 -------
(In reply to comment #2)
> The "problem" to me is that we don't do this splitting of 32on64 versus "pure
> 64" bit syscalls consistently. Why do we have syscall.pipe32 and syscall.mmap32,
> but not syscall.fstat32 for example?
> 
> syscall.fstat is a nice example since we make it match any syscall variant that
> is called "fstat" whether it is the "plain" one or the compat/32on64 version.

I believe the reasons are mostly historical.  I'd guess that when there were
argument differences between the 32-bit and 64-bit syscall, the '32' probe
variant would be created.  (I realize this doesn't account for the
syscall.pipe/syscall.pipe32 case, but who said we were 100% consistent?)

If this tapset would be written today, it would probably be written like (untested):

====
probe _syscall.foo = kernel.function("sys_foo") {
  # handle arguments...
}
probe _syscall.foo32 = kernel.function("sys_foo32") ? {
  # handle 32-bit arguments...
}
probe syscall.foo = _syscall.foo, _syscall.foo32
====

Now the question we have to think about is: If we refactor the syscall.foo32
probes, how many existing scripts do we break?


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11263

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