I''m using a fbt probe where I get a system call id as an argument, how do I look up the name of it? At the moment I''m post-processing the output using /etc/name/to_sysnum but that doesn''t feel right :) cheers, /Martin -- This message posted from opensolaris.org
Martin Englund wrote:> I''m using a fbt probe where I get a system call id as an argument, how do I > look up the name of it? At the moment I''m post-processing the output using > /etc/name/to_sysnum but that doesn''t feel right :)idea: speculate on syscall:::entry, store probefunc, and commit the speculation when the fbt probe you''re interested in fires. HTH Michael -- Michael Schuster Recursion, n.: see ''Recursion''
Thanks for the suggestion. This is how the probes fire: fbt:c2audit:audit_start:entry fbt:c2audit:audit_start:return syscall:::entry syscall:::return fbt:c2audit:audit_finish:entry fbt:c2audit:audit_finish:return I guess I can just save the timing data I calculate in fbt:c2audit:audit_start:return and add it to my aggregation when I''m in fbt:c2audit:audit_finish:return. cheers, /Martin -- This message posted from opensolaris.org
On Wed, Aug 29, 2007 at 11:31:13AM -0700, Martin Englund wrote:> Thanks for the suggestion. This is how the probes fire: > > fbt:c2audit:audit_start:entry > fbt:c2audit:audit_start:return > syscall:::entry > syscall:::return > fbt:c2audit:audit_finish:entry > fbt:c2audit:audit_finish:return > > I guess I can just save the timing data I calculate in > fbt:c2audit:audit_start:return and add it to my aggregation when I''m > in fbt:c2audit:audit_finish:return.And you don''t even need to use a speculation -- thread locals should suffice, no?
Hi Martin,> I''m using a fbt probe where I get a system call id as an argument, how do I look up the name of it? At the moment I''m post-processing the output using /etc/name/to_sysnum but that doesn''t feel right :)This may not be quite what you want for your particular issue but a way to answer the initial question is to use the sysent[] array to extract this information. An example using post_syscall(): fbt::post_syscall:entry { this->call = curthread->t_sysnum; this->addr = (struct sysent *)((char *)&`sysent + this->call * sizeof(struct sysent)); @calls[this->addr->sy_callc] = count(); } END { printa("%30a\t\t%@d\n", @calls); } # ./sysent.d ^C genunix`lwp_cond_wait 1 genunix`sigsuspend 2 genunix`syslwp_park 3 genunix`read 4 genunix`getsetcontext 7 genunix`lwp_sigmask 19 genunix`pollsys 44 genunix`p_online 62 genunix`ioctl 125 Jon.
Excellent! Exactly what I was looking for. cheers, /Martin -- This message posted from opensolaris.org
On 8/30/07, Jon Haslam <Jonathan.Haslam at sun.com> wrote:> > Hi Martin, > > > I''m using a fbt probe where I get a system call id as an argument, how > do I look up the name of it? At the moment I''m post-processing the output > using /etc/name/to_sysnum but that doesn''t feel right :) > > This may not be quite what you want for your particular issue but > a way to answer the initial question is to use the sysent[] array > to extract this information. An example using post_syscall(): > > > fbt::post_syscall:entry > { > this->call = curthread->t_sysnum; > > this->addr = (struct sysent *)((char *)&`sysent + > this->call * sizeof(struct sysent)); > > @calls[this->addr->sy_callc] = count();Note that this will *NOT* work on system calls which have active syscall:::{entry,return} probes enabled; you''ll just get dtrace_syscall_syscall for them as long as the probes are enabled. You *could* probably just do: @calls[`systrace_sysent[curthread->t_sysnum].stsy_underlying] = count(); to get a reliable function pointer. This is, of course, not a documented interface; caveat emptor. In either case, you''ll be getting the underlying C function name, not the syscall name, so there will be slight mismatches ("rexit" instead of "exit", for example). There''s also a 32-bit v.s. 64-bit issue under the covers here. Cheers, - jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20070830/6ea34d67/attachment.html>