[Bug translator/10045] New: process.syscall(NUM) probes

[Bug translator/10045] New: process.syscall(NUM) probes

[fche at redhat dot com]

In the future, we will probably extend or twin the syscall.* tapset
to utrace-based high-performance probes.  However, utrace per se doesn't
provide efficient per-syscall-type filtering, so if it were implemented
thusly:

probe process.syscall.read = process.syscall {
  if ($syscall_nr!=30) next
  arg1=@cast(...)
}
....

then multiple syscall probes can't be very efficiently implemented,
since it would translate to a chain of if/else's or worse, just to
evaluate the syscall_nr comparison/rejection logic.

If OTOH the syscall number was pushed into the probe point, as in
  probe process.syscall(NUM) {...}
then the translator can emit a more efficient switch block in case
of multiple syscall probes.

-- 
           Summary: process.syscall(NUM) probes
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: fche at redhat dot com


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

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

[Bug translator/10045] process.syscall(NUM) probes

[dsmith at redhat dot com]

------- Additional Comments From dsmith at redhat dot com  2009-04-13 14:19 -------
(In reply to comment #0)
> If OTOH the syscall number was pushed into the probe point, as in
>   probe process.syscall(NUM) {...}
> then the translator can emit a more efficient switch block in case
> of multiple syscall probes.

This is probably a good idea.  I got 2 thoughts here:

(1) I wonder if we shouldn't go a bit farther and allow users to specify system
calls by name,  instead of by number.  Keeping track of the numbers will be
difficult for script writers.  For instance, here are the numbers for the mmap
and mmap2 syscalls on various platforms:

x86:     90   192
x86_64:   9   
ppc:     90   192
ia64:  1151  1172
s390:    90   192

Then things get even more confusing when running a 32-bit executable on a 64-bit
platform.  For instance, on x86_64, when running a 64-bit executable, the
syscall number for mmap as shown above is 9.  But, when running a 32-bit
executable on that same x86_64 system, you have to look for either 90 (mmap) or
192 (mmap2).

So, I wonder if we couldn't end up with something like this:

   probe process.syscall(SYS_MMAP) {...}

or perhaps:

   probe process.syscall(syscall_num(SYS_MMAP)) {...}

(2) I also wonder if it would be a good idea to accept a list of numbers (or
names), like this:

   probe process.syscall(NUM1, NUM2, NUM3) {...}


-- 


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

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

[Bug translator/10045] process.syscall(NUM) probes

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2009-04-16 17:42 -------
> (1) I wonder if we shouldn't go a bit farther and allow users to specify system
> calls by name,  instead of by number.  Keeping track of the numbers will be
> difficult for script writers.

It would be OK to encode these into the tapset ...

> [...] For instance, on x86_64, when running a 64-bit executable, the
> syscall number for mmap as shown above is 9.  But, when running a 32-bit
> executable on that same x86_64 system, you have to look for either 90 (mmap) or
> 192 (mmap2).

... except for this detail.

If the numbers are run-time variable then we lose the advantage of exposing
them to the compiler to generate a nice switch table from multiple probes.

Maybe a suitable tapset-only hack could be ...

tapset/x86_64/utrace-syscalls.stp:

probe process.syscall.mmap.x86 = process.syscall(90), process.syscall(192) { 
   if (! task_arch ("i686")) next;
}
probe process.syscall.mmap.x86_64 = process.syscall(9) {
   if (! task_arch ("x86_64")) next;
}
probe process.syscall.mmap = process.syscall.mmap.* { }

(For tapset/i686/utrace-syscalls.stp, it would expand only to the first.)


> (2) I also wonder if it would be a good idea to accept a list of numbers (or
> names), like this:
>    probe process.syscall(NUM1, NUM2, NUM3) {...}

Probably unnecessary;  "probe process.syscall(NUM1), process.syscall(NUM2) {}" 
is a reasonable way to express small number of alternatives.


-- 


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

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

[Bug translator/10045] process.syscall(NUM) probes

[dsmith at redhat dot com]

------- Additional Comments From dsmith at redhat dot com  2009-04-16 19:59 -------
(In reply to comment #2)
> > (1) I wonder if we shouldn't go a bit farther and allow users to specify system
> > calls by name,  instead of by number.  Keeping track of the numbers will be
> > difficult for script writers.
> 
> It would be OK to encode these into the tapset ...
> 
> > [...] For instance, on x86_64, when running a 64-bit executable, the
> > syscall number for mmap as shown above is 9.  But, when running a 32-bit
> > executable on that same x86_64 system, you have to look for either 90 (mmap) or
> > 192 (mmap2).
> 
> ... except for this detail.
> 
> If the numbers are run-time variable then we lose the advantage of exposing
> them to the compiler to generate a nice switch table from multiple probes.

I can see that.

> Maybe a suitable tapset-only hack could be ...
> 
> tapset/x86_64/utrace-syscalls.stp:
> 
> probe process.syscall.mmap.x86 = process.syscall(90), process.syscall(192) { 
>    if (! task_arch ("i686")) next;
> }
> probe process.syscall.mmap.x86_64 = process.syscall(9) {
>    if (! task_arch ("x86_64")) next;
> }
> probe process.syscall.mmap = process.syscall.mmap.* { }
> 
> (For tapset/i686/utrace-syscalls.stp, it would expand only to the first.)

That's an interesting idea.  The only small nit I have about it is the code
duplication between x86_64/utrace-syscalls.stp and i686/utrace-syscalls.stp.
 
> > (2) I also wonder if it would be a good idea to accept a list of numbers (or
> > names), like this:
> >    probe process.syscall(NUM1, NUM2, NUM3) {...}
> 
> Probably unnecessary;  "probe process.syscall(NUM1), process.syscall(NUM2) {}" 
> is a reasonable way to express small number of alternatives.

I was thinking the translator could generate a nicer switch table if it knew up
front all the syscall numbers this probe applied to.



-- 


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

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