Hi,
Anyone knows about the vtrace provider? When I was reading the code, I
find some traces like TRACE_1, TRACE_2, etc. The comments says they''re
now replaced by Dtrace''s vtrace provider, but I couldn''t find
any
documents about this vtrace provider. I googled and searched on
docs.sun, and found nothing.
I also saw the definitions:
#define TRACE_1(fac, tag, name, d1) { \
extern void __dtrace_probe___vtrace_##tag(ulong_t); \
__dtrace_probe___vtrace_##tag((ulong_t)(d1)); \
}
But I couldn''t find any __dtrace_probe___vtrace_* definitions in the
code. Can anyone give some hints?
--Tuma
Hi Tuma,> Anyone knows about the vtrace provider? When I was reading the code, I > find some traces like TRACE_1, TRACE_2, etc. The comments says they''re > now replaced by Dtrace''s vtrace provider, but I couldn''t find any > documents about this vtrace provider. I googled and searched on > docs.sun, and found nothing. > > > I also saw the definitions: > > #define TRACE_1(fac, tag, name, d1) { \ > extern void __dtrace_probe___vtrace_##tag(ulong_t); \ > __dtrace_probe___vtrace_##tag((ulong_t)(d1)); \ > } > > But I couldn''t find any __dtrace_probe___vtrace_* definitions in the > code. Can anyone give some hints?Not quite sure what you mean. The TRACE_() definitions that you cite in sys/vtrace.h are used in DEBUG kernels only. Every time you find a TRACE_() call in the source it will be replaced with the above SDT based probes - do a `dtrace -l -P vtrace` on a debug kernel to see the probes. On regular, non debug kernel you won''t see any vtrace probes. I would have thought the comment at the top of sys/vtrace.h explains what the vtrace provider is and what its purpose is. Does this not do it for you? Jon.
> Hi Tuma,Hi Jon, thanks for the response.>> Anyone knows about the vtrace provider? When I was reading the code, I >> find some traces like TRACE_1, TRACE_2, etc. The comments says they''re >> now replaced by Dtrace''s vtrace provider, but I couldn''t find any >> documents about this vtrace provider. I googled and searched on >> docs.sun, and found nothing. >> >> >> I also saw the definitions: >> >> #define TRACE_1(fac, tag, name, d1) { \ >> extern void __dtrace_probe___vtrace_##tag(ulong_t); \ >> __dtrace_probe___vtrace_##tag((ulong_t)(d1)); \ >> } >> >> But I couldn''t find any __dtrace_probe___vtrace_* definitions in the >> code. Can anyone give some hints? > > Not quite sure what you mean. The TRACE_() definitions that you > cite in sys/vtrace.h are used in DEBUG kernels only. Every time you find > a TRACE_() call in the source it will be replaced with the above SDT based > probes - do a `dtrace -l -P vtrace` on a debug kernel to see the probes. On > regular, non debug kernel you won''t see any vtrace probes. > > I would have thought the comment at the top of sys/vtrace.h explains > what the vtrace provider is and what its purpose is. Does this not do > it for you? > > Jon.The comments at the top of sys/vtrace.h explains the background, but doesn''t state in detail how to use it. In particular, what the type and the format of the arguments are. For example, to monitor this (in uts/common/inet/ip/ip.c) TRACE_1(TR_FAC_IP, TR_IP_RPUT_START, "ip_input_start: q %p", q); I tried this script: #!/usr/sbin/dtrace -s vtrace:ip:ip_input:TR_IP_RPUT_START { trace("__ called\n"); trace(arg0); trace(arg1); trace(arg2); trace(arg3); trace(arg4); } And got: $ ./vtrace.d dtrace: script ''./vtrace.d'' matched 1 probe CPU ID FUNCTION:NAME 16 1055 ip_input:TR_IP_RPUT_START __ called 3299361532608 2074207392 3299406004288 20289536 33554432 16 1055 ip_input:TR_IP_RPUT_START __ called 3299361532608 2074207392 3299406004288 20289536 33554432 16 1055 ip_input:TR_IP_RPUT_START __ called 3299361532608 2074207392 3299406004288 20289536 33554432 16 1055 ip_input:TR_IP_RPUT_START __ called 3299361532608 2074207392 3299406004288 20289536 33554432 16 1055 ip_input:TR_IP_RPUT_START __ called 3299361532608 2074207392 3299406004288 20289536 33554432 16 1055 ip_input:TR_IP_RPUT_START __ called 3299361532608 2074207392 3299406004288 20289536 33554432 How can I get the "q", which is queue_t? How many arguments does it have? I guess 1 or 2, but as you can see, I tried arg3 and arg4 but didn''t get error or warning. Etc. Maybe experienced guys can figure out them easily, but not for me. Also, where can I find these __dtrace_probe___vtrace_* definitions? Thanks. -- Tuma
> The comments at the top of sys/vtrace.h explains the background, but > doesn''t state in detail how to use it. In particular, what the type > and the format of the arguments are. > > For example, to monitor this (in uts/common/inet/ip/ip.c) > TRACE_1(TR_FAC_IP, TR_IP_RPUT_START, "ip_input_start: q %p", q);The digit given in the TRACE_?() macros specify how many arguments are being provided, so with TRACE_1() there is 1 argument. Unfortunately, the vtrace probes don''t have their argument type information exported so you can''t use the args[] array to access them or the ''-v'' flag to dtrace(1M). In this case you need to use the source to look at the arguments and then either use the source or mdb(1) to look at the types. Then you cast the arguments accordingly. So, with your example of vtrace:ip:ip_input:TR_IP_RPUT_START, this takes a single argument of a queue_t pointer as you state. To use this just do something like: vtrace:ip:ip_input:TR_IP_RPUT_START { this->queue = (queue_t *)arg0; printf("High Water = %d\n", this->queue->q_hiwat); } As I said, to find the definition of a queue_t, either use the source or mdb: # mdb -k Loading modules: [ unix genunix dtrace specfs ufs scsi_vhci sd isp pcisch sgsbbc ip hook neti sctp arp fctl nca lofs zfs random ipc sppp cpc ptm nfs fcip logindmux ] > ::print -t queue_t { struct qinit *q_qinfo struct msgb *q_first struct msgb *q_last struct queue *q_next struct queue *q_link <chop> Hope this helps. Jon.
Thanks Jon, your explanation is very helpful.
One more question: in this definition,
TRACE_1(TR_FAC_IP, TR_IP_RPUT_START, "ip_input_start: q %p",
q);
only "q" is an argument. Where does the "ip_input_start: q
%p" stuff
go? Or, what is it used?
Thanks.
On Fri, May 30, 2008 at 7:28 PM, Jon Haslam <Jonathan.Haslam at sun.com>
wrote:>
>> The comments at the top of sys/vtrace.h explains the background, but
>> doesn''t state in detail how to use it. In particular, what the
type
>> and the format of the arguments are.
>>
>> For example, to monitor this (in uts/common/inet/ip/ip.c)
>> TRACE_1(TR_FAC_IP, TR_IP_RPUT_START, "ip_input_start: q
%p", q);
>
> The digit given in the TRACE_?() macros specify how many arguments
> are being provided, so with TRACE_1() there is 1 argument. Unfortunately,
> the vtrace probes don''t have their argument type information
exported
> so you can''t use the args[] array to access them or the
''-v'' flag
> to dtrace(1M). In this case you need to use the source to look at the
> arguments and then either use the source or mdb(1) to look at the types.
> Then you cast the arguments accordingly.
>
> So, with your example of vtrace:ip:ip_input:TR_IP_RPUT_START, this
> takes a single argument of a queue_t pointer as you state. To use
> this just do something like:
>
> vtrace:ip:ip_input:TR_IP_RPUT_START
> {
> this->queue = (queue_t *)arg0;
> printf("High Water = %d\n", this->queue->q_hiwat);
> }
>
> As I said, to find the definition of a queue_t, either use the
> source or mdb:
>
> # mdb -k
> Loading modules: [ unix genunix dtrace specfs ufs scsi_vhci sd isp pcisch
> sgsbbc ip hook neti sctp arp fctl nca lofs zfs random ipc sppp cpc ptm nfs
> fcip logindmux ]
>> ::print -t queue_t
> {
> struct qinit *q_qinfo
> struct msgb *q_first
> struct msgb *q_last
> struct queue *q_next
> struct queue *q_link
> <chop>
>
> Hope this helps.
>
> Jon.
>
> One more question: in this definition, > TRACE_1(TR_FAC_IP, TR_IP_RPUT_START, "ip_input_start: q %p", q); > only "q" is an argument. Where does the "ip_input_start: q %p" stuff > go? Or, what is it used?It is no longer used. It''s just a vestige of a tracing system from bygone days. Jon.> > Thanks. > > > On Fri, May 30, 2008 at 7:28 PM, Jon Haslam <Jonathan.Haslam at sun.com> wrote: >>> The comments at the top of sys/vtrace.h explains the background, but >>> doesn''t state in detail how to use it. In particular, what the type >>> and the format of the arguments are. >>> >>> For example, to monitor this (in uts/common/inet/ip/ip.c) >>> TRACE_1(TR_FAC_IP, TR_IP_RPUT_START, "ip_input_start: q %p", q); >> The digit given in the TRACE_?() macros specify how many arguments >> are being provided, so with TRACE_1() there is 1 argument. Unfortunately, >> the vtrace probes don''t have their argument type information exported >> so you can''t use the args[] array to access them or the ''-v'' flag >> to dtrace(1M). In this case you need to use the source to look at the >> arguments and then either use the source or mdb(1) to look at the types. >> Then you cast the arguments accordingly. >> >> So, with your example of vtrace:ip:ip_input:TR_IP_RPUT_START, this >> takes a single argument of a queue_t pointer as you state. To use >> this just do something like: >> >> vtrace:ip:ip_input:TR_IP_RPUT_START >> { >> this->queue = (queue_t *)arg0; >> printf("High Water = %d\n", this->queue->q_hiwat); >> } >> >> As I said, to find the definition of a queue_t, either use the >> source or mdb: >> >> # mdb -k >> Loading modules: [ unix genunix dtrace specfs ufs scsi_vhci sd isp pcisch >> sgsbbc ip hook neti sctp arp fctl nca lofs zfs random ipc sppp cpc ptm nfs >> fcip logindmux ] >>> ::print -t queue_t >> { >> struct qinit *q_qinfo >> struct msgb *q_first >> struct msgb *q_last >> struct queue *q_next >> struct queue *q_link >> <chop> >> >> Hope this helps. >> >> Jon. >>