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