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

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

[krebbel1 at de dot ibm.com]

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

Andreas Krebbel <krebbel1 at de dot ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |krebbel1 at de dot ibm.com,
                   |                            |stli at linux dot vnet.ibm.com

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

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

[fche at redhat dot com]

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

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #4 from Frank Ch. Eigler <fche at redhat dot com> ---
this does not still seem so helpful, with the nd_syscall.* tapset

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

[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.

[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-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.