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
_______________________________________________
dtrace-discuss mailing list
[email protected]