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]

Reply via email to