> > 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
pgpdInSDNyD40.pgp
Description: PGP signature
_______________________________________________ dtrace-discuss mailing list [email protected]
