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