dtrace discuss - Feb 2008 - Is there way to trace memory in the dtrace ?

N_conreq:entry {
        self->x=1;

        calledaddr=(struct xaddrf *)arg3;
        callingaddr=(struct xaddrf *)arg4;

        trace(calledaddr->link_id);
        tracemem(calledaddr->DTE_MAC.lsap_add, 80);

        trace(callingaddr->link_id);
        tracemem(callingaddr->DTE_MAC.lsap_add, 80);
}

  0  -> N_conreq                                    255                      
<===== first link_id
             0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f  0123456789abcdef 
<===== first tracemem
         0: 12 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00  .0..............
        10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        20: 00 ff 00 03 45 60 00 00 00 00 00 00 00 00 00 00  ....E`..........
        30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      255  E`
      ^    ^-- dtrace being smart here? The memory is 0x45 0x60 0x00 ... which
is E` in ascii.
2nd link_id

Is there a way to really trace 80 bytes of memory?

Thank you

-- 
	Vlad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 193 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20080226/6874274a/attachment.bin>

On Tue, Feb 26, 2008 at 03:56:36PM +0100, Vladimir Marek
wrote:
> N_conreq:entry {
>         self->x=1;
> 
>         calledaddr=(struct xaddrf *)arg3;
>         callingaddr=(struct xaddrf *)arg4;
> 
>         trace(calledaddr->link_id);
>         tracemem(calledaddr->DTE_MAC.lsap_add, 80);
> 
>         trace(callingaddr->link_id);
>         tracemem(callingaddr->DTE_MAC.lsap_add, 80);
> }
> 
>   0  -> N_conreq                                    255                 
<===== first link_id
>              0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f 
0123456789abcdef  <===== first tracemem
>          0: 12 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
.0..............
>         10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
>         20: 00 ff 00 03 45 60 00 00 00 00 00 00 00 00 00 00 
....E`..........
>         30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
>         40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
>       255  E`
>       ^    ^-- dtrace being smart here? The memory is 0x45 0x60 0x00 ...
which is E` in ascii.
> 2nd link_id
> 
> Is there a way to really trace 80 bytes of memory?
As is usually the case with DTrace, there _is_ a way, but, as is ocassionally
the case, it''s not beautiful. There''s a bug here in that
DTrace -- as you
suspected -- tries to be a little bit too clever when printing bytes by
assuming that you must want something printed as a string if the first few
bytes are printable.

What you can do is create a buffer to hold your real data, prepend it with
a non-printable character, and trace the whole thing (remembering to mentally
discard the first byte). For example:

syscall::write:entry
/execname == "cat"/
{
        this->a = copyin(arg1, 80);
        this->p = (char *)alloca(81);
        *this->p = ''\0'';
        bcopy(this->a, this->p + 1, 80);
        tracemem(this->p, 81);
}

Despite this glorious work-around, please file a bug; if someone is interested
in getting involved with DTrace development, this would be a good fix to try
out.

Adam

-- 
Adam Leventhal, Fishworks                        http://blogs.sun.com/ahl

Adam Leventhal wrote:
> What you can do is create a buffer to hold your real data, prepend it with
> a non-printable character, and trace the whole thing (remembering to
mentally
> discard the first byte). For example:
> 
> syscall::write:entry
> /execname == "cat"/
> {
>         this->a = copyin(arg1, 80);
>         this->p = (char *)alloca(81);
>         *this->p = ''\0'';
>         bcopy(this->a, this->p + 1, 80);
>         tracemem(this->p, 81);
> }
> 
> Despite this glorious work-around, 
chuckle.
> please file a bug; if someone is interested
> in getting involved with DTrace development, this would be a good fix to
try
> out.
Spouting off ideas: perhaps tracerawmem()?

On Thu, Feb 28, 2008 at 11:15:30AM -0800, Dan Mick
wrote:
> Adam Leventhal wrote:
> > What you can do is create a buffer to hold your real data, prepend it
with
> > a non-printable character, and trace the whole thing (remembering to
mentally
> > discard the first byte). For example:
> > 
> > syscall::write:entry
> > /execname == "cat"/
> > {
> >         this->a = copyin(arg1, 80);
> >         this->p = (char *)alloca(81);
> >         *this->p = ''\0'';
> >         bcopy(this->a, this->p + 1, 80);
> >         tracemem(this->p, 81);
> > }
> > 
> > Despite this glorious work-around, 
> 
> chuckle.
> 
> > please file a bug; if someone is interested
> > in getting involved with DTrace development, this would be a good fix
to try
> > out.
> 
> Spouting off ideas: perhaps tracerawmem()?
You don''t actually even need to do that -- this can be done purely in
terms of implementation changes.  (We just need to break out tracemem()
as its own action type -- DTRACEACT_TRACEMEM -- and then act on that
accordingly at user-land.  As Adam said, it''s a good project for
someone
to pick up who is interested in getting their feet wet with DTrace.)

	- Bryan

--------------------------------------------------------------------------
Bryan Cantrill, Sun Microsystems Fishworks.       http://blogs.sun.com/bmc

> >         tracemem(callingaddr->DTE_MAC.lsap_add, 80);
...
> >   0  -> N_conreq                                    255            
<===== first link_id
> >              0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f 
0123456789abcdef  <===== first tracemem
> >          0: 12 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
.0..............
> >         10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
> >         20: 00 ff 00 03 45 60 00 00 00 00 00 00 00 00 00 00 
....E`..........
> >         30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
> >         40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
................
> >       255  E`
> >       ^    ^-- dtrace being smart here? The memory is 0x45 0x60 0x00
... which is E` in ascii.
> > 2nd link_id
> > 
> > Is there a way to really trace 80 bytes of memory?

[...]
> What you can do is create a buffer to hold your real data, prepend it with
> a non-printable character, and trace the whole thing (remembering to
mentally
> discard the first byte). For example:
> 
> syscall::write:entry
> /execname == "cat"/
> {
>         this->a = copyin(arg1, 80);
>         this->p = (char *)alloca(81);
>         *this->p = ''\0'';
>         bcopy(this->a, this->p + 1, 80);
>         tracemem(this->p, 81);
> }
I was thinking about doing the same, but I didn''t know that there are
alloca and bcopy functions. 

> Despite this glorious work-around, please file a bug; if someone is
interested
> in getting involved with DTrace development, this would be a good fix to
try
> out.
4937796 trace() and tracemem() should provide option to force hex output

fixed in s10_64

It''s rawbytes option. So this works like a charm

dtrace -x rawbytes -n ''syscall::write:entry/execname ==
"cat"/{tracemem(copyin(arg1,80),80)}''


Next time I''ll know better, don''t trust manual, use the source
:( :( :(

Thank Adam

-- 
	Vlad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 193 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20080228/83647270/attachment.bin>

[...]
> > Spouting off ideas: perhaps tracerawmem()?
> 
> You don''t actually even need to do that -- this can be done purely
in
> terms of implementation changes.  (We just need to break out tracemem()
> as its own action type -- DTRACEACT_TRACEMEM -- and then act on that
> accordingly at user-land.  As Adam said, it''s a good project for
someone
> to pick up who is interested in getting their feet wet with DTrace.)
Bryan, you seem to be responsible engineer for long time ago closed CR ;)

4937796 trace() and tracemem() should provide option to force hex output

I don''t see any use for additional dtrace modifications. If you want to
print string, use trace() or printf(). If you want to hexdump use
tracemem() with rawbytes option.

-- 
	Vlad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 193 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20080228/880b6594/attachment.bin>

> > > Spouting off ideas: perhaps tracerawmem()?
> > 
> > You don''t actually even need to do that -- this can be done
purely in
> > terms of implementation changes.  (We just need to break out
tracemem()
> > as its own action type -- DTRACEACT_TRACEMEM -- and then act on that
> > accordingly at user-land.  As Adam said, it''s a good project
for someone
> > to pick up who is interested in getting their feet wet with DTrace.)
> 
> Bryan, you seem to be responsible engineer for long time ago closed CR ;)
> 
> 4937796 trace() and tracemem() should provide option to force hex output
> 
> I don''t see any use for additional dtrace modifications. If you
want to
> print string, use trace() or printf(). If you want to hexdump use
> tracemem() with rawbytes option.
Ah yes, right.  You would think that I would remember this given that 
I added it, but you''d be wrong. ;)  Now the real question:  why did I
do it this way instead of what seems to me (now) to be the better fix
of making tracemem() its own action?  Would someone please offer to
put me under hypnosis so I can answer my own question? ;)

	- Bryan

--------------------------------------------------------------------------
Bryan Cantrill, Sun Microsystems Fishworks.       http://blogs.sun.com/bmc

On Thu, Feb 28, 2008 at 08:35:15PM +0100, Vladimir Marek
wrote:
> I was thinking about doing the same, but I didn''t know that there
are
> alloca and bcopy functions. 
Right. If anyone is interested in contributing by documenting those
subroutines, please send some text to the list for approval before you
add it to the wiki. Thanks.

Adam

-- 
Adam Leventhal, Fishworks                        http://blogs.sun.com/ahl

> > I was thinking about doing the same, but I didn''t know that
there are
> > alloca and bcopy functions. 
> 
> Right. If anyone is interested in contributing by documenting those
> subroutines, please send some text to the list for approval before you
> add it to the wiki. Thanks.
Ah, too late, sorry. If there is such process, it would be nice having
the wiki to warn you. But I''ll know better next time.

If you want to review my changes, they are 
http://wikis.sun.com/pages/diffpages.action?pageId=10391677&originalId=13606601
and
http://wikis.sun.com/pages/diffpages.action?pageId=10391482&originalId=13606608

-- 
	Vlad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 193 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20080228/44786382/attachment.bin>

On Thu, Feb 28, 2008 at 09:46:24PM +0100, Vladimir Marek
wrote:
> > > I was thinking about doing the same, but I didn''t know
that there are
> > > alloca and bcopy functions. 
> > 
> > Right. If anyone is interested in contributing by documenting those
> > subroutines, please send some text to the list for approval before you
> > add it to the wiki. Thanks.
> 
> Ah, too late, sorry. If there is such process, it would be nice having
> the wiki to warn you. But I''ll know better next time.
> 
> If you want to review my changes, they are 
>
http://wikis.sun.com/pages/diffpages.action?pageId=10391677&originalId=13606601
> and
>
http://wikis.sun.com/pages/diffpages.action?pageId=10391482&originalId=13606608
Thanks for doing this!  I changed the language slightly to make the voice
consistent with the other descriptions.  Incidentally, if anyone is 
interested in documenting the other undocumented options, the bodies are
all buried here:

 
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libdtrace/common/dt_options.c#_dtrace_ctoptions

Some of these -- perhaps even most -- are undocumented by design, so
definitely send some diffs out before you get too carried away... ;)

And if one wants the action/subroutine equivalent, those bodies are buried
over here:

 
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libdtrace/common/dt_open.c#_dtrace_globals

	- Bryan

--------------------------------------------------------------------------
Bryan Cantrill, Sun Microsystems Fishworks.       http://blogs.sun.com/bmc

On FreeBSD I have implemented a printm() action.

I particularly wanted to have a variable length argument so that I could trace
memory where the size is determined by something in the code like the protocol.

My syntax is a bit icky due to parser and DIF emulation issues, but it works.
:-)

printm(fixed_buf_len, memref( mem_ptr, var_length ));

The ''fixed_buf_len'' field (like the length arg to tracemem())
determines the ECB buffer space allocated for the action.

The ''mem_ptr'' is any memory address resolved by DIF.

The ''var_length'' is an integer value resolved by DIF.

The memref() is a DIF_SUBR introduced only to get around the single valued
return by the DIF emulation. It returns an array of uintptr_t''s
allocated from scratch memory.

The printm() action, when processed by dt_consume_cpu in user space decodes the
length of the data following and then calls print_bytes which I''ve
modified to pass an extra argument to force raw output.

I also have a printt() action which will take a pointer to any non-void type
plus the number of elements and print the structure/union/type names and values
in a debugger-ish way.

I have listed the printa() and printt() actions as a topic for discussion at
dtrace.conf(08).


--
This message posted from opensolaris.org

On Thu, Feb 28, 2008 at 01:38:50PM -0800, John Birrell
wrote:
> On FreeBSD I have implemented a printm() action.
> 
> I particularly wanted to have a variable length argument so that I could
trace memory where the size is determined by something in the code like the
protocol.
> 
> My syntax is a bit icky due to parser and DIF emulation issues, but it
works. :-)
> 
> printm(fixed_buf_len, memref( mem_ptr, var_length ));
> 
> The ''fixed_buf_len'' field (like the length arg to
tracemem()) determines the ECB buffer space allocated for the action.
> 
> The ''mem_ptr'' is any memory address resolved by DIF.
> 
> The ''var_length'' is an integer value resolved by DIF.
> 
> The memref() is a DIF_SUBR introduced only to get around the single valued
return by the DIF emulation. It returns an array of uintptr_t''s
allocated from scratch memory.
> 
> The printm() action, when processed by dt_consume_cpu in user space decodes
the length of the data following and then calls print_bytes which I''ve
modified to pass an extra argument to force raw output.
Yuck.  I definitely like the functionality, and I definitely don''t like
the interface.  Instead, tracemem() should be able to take a DIF expression
as a second argument -- in which case there must be a third argument that
is the (static) length of the buffer.  (Or, arguably, there should just be
an optional third argument to tracemem() which is a DIF expression containing
the number of bytes to trace.)  Yes, it requires some deeper implementation
changes -- but we always prefer implementation complexity to abstraction
complexity.
> I also have a printt() action which will take a pointer to any non-void
type plus the number of elements and print the structure/union/type names and
values in a debugger-ish way.
That sounds great!  My only comment there would be that it should just be
print(), and its output should be like mdb''s ::print.  This is a
long-standing
RFE, so it would be great to get this back.
> I have listed the printa() and printt() actions as a topic for discussion
at dtrace.conf(08).
Very good -- we''ll discuss more then!

	- Bryan

--------------------------------------------------------------------------
Bryan Cantrill, Sun Microsystems Fishworks.       http://blogs.sun.com/bmc