dtrace discuss - Jun 2008 - Passing pointer-to-struct to USDT probes

Hi!

I''m in the process of adding USDT probes to MySQL Proxy and am  
experiencing some problems with my approach.

For example, I have one probe that fires when the state of a  
connection changes (the state machine is based on the MySQL protocol):
(FYI, this is all done on OS X but everything is applicable to  
OpenSolaris as well)

the provider .d file contains:
--------
provider mysql_proxy {
     probe state__change(int, short, void *);
};
--------

In a source file I invoke the probe with:
  MYSQL_PROXY_STATE_CHANGE(event_fd, events, con);

event_fd and events are int and short, respectively.
con actually is: network_mysqld_con *con;

Now the problems start: I meant to pass in high-level information into  
the probe, because that will maximize the flexibility of writing  
scripts.
But now writing a D script that makes use of con means either
  - including the structs and enums in the script
  - including the original header file and using that
  - doing lots and lots of error prone copyin(arg2 + xxx,  
sizeof(type)), which is neither elegant nor nice on the script author

Because ''typedef struct { ... } network_mysqld_con'' is
actually a non-
trivial struct and refers to various other structs and enums it''s not  
a good idea to copy it in. Things _will_ get out of sync.

Including the original header didn''t work either, because
that''s
eventually pulling in system headers that define functions which break  
the script compilation (I''ve seen this problem on both OS X and  
OpenSolaris. E.g. OS X chokes on /usr/include/sys/_structs.h)

Which leaves me with option 3 and that''s equally burdensome and  
errorprone, especially given the multitude of structs I have to deal  
with. Much of the flexibility about DTrace would be sacrificed if I  
would pass in only a few specific members of the structs, too.

What is the current best-practice for this kind of situation? [1]
I have read about DTrace translators
(<http://blogs.sun.com/tdd/entry/example_of_a_dtrace_translator
 >) but I think that''s only available for DTrace >= 1.5, correct?
Apple''s implementation seems to be 1.2.2, if I can believe its output.
Also, the translators seem to make it easier for the script writer,  
but can''t solve the underlying maintenance problem.

Essentially I''m coming to think that this calls for a simple tool that
takes struct definitions and produces suitable D code for prying them  
apart again, without pulling in all of the headers involved. Then the  
actual struct access could either be implemented using translators if  
available or by using copyin(arg + offset, sizeof()). The entire thing  
could futher be hidden behind macros, which could live in header files  
shipped with the actual product. Those would be generated at build  
time. Does that even remotely sound like a good idea?

Thanks,
-k

[1] I''ve seen
http://src.opensolaris.org/source/xref/jds/spec-files/trunk/patches/Python-07-dtrace.diff#263
  and http://prefetch.net/projects/apache_modtrace/scripts/ 
apachetop.pl as examples and both seem to go down a path I don''t  
really wanna tread... :(
-- 
Kay Roepke
Software Engineer, MySQL Enterprise Tools

Sun Microsystems GmbH    Sonnenallee 1, DE-85551 Kirchheim-Heimstetten
Geschaeftsfuehrer: Thomas Schroeder, Wolfang Engels, Dr. Roland Boemer
Vorsitz d. Aufs.rat.: Martin Haering                    HRB MUC 161028

On Jun 17, 2008, at 4:47 AM, Kay R?pke wrote:
>
> Now the problems start: I meant to pass in high-level information into
> the probe, because that will maximize the flexibility of writing
> scripts.
> But now writing a D script that makes use of con means either
>  - including the structs and enums in the script
>  - including the original header file and using that
>  - doing lots and lots of error prone copyin(arg2 + xxx,
> sizeof(type)), which is neither elegant nor nice on the script author
>
> Because ''typedef struct { ... } network_mysqld_con'' is
actually a non-
> trivial struct and refers to various other structs and enums it''s
not
> a good idea to copy it in. Things _will_ get out of sync.
	At first glance, it seems like user space CTF would be a big
win here.

	James M

On Tue, Jun 17, 2008 at 01:57:20PM -0700, James McIlree wrote:
> > Now the problems start: I meant to pass in high-level information into
> > the probe, because that will maximize the flexibility of writing
> > scripts.
> > But now writing a D script that makes use of con means either
> >  - including the structs and enums in the script
> >  - including the original header file and using that
> >  - doing lots and lots of error prone copyin(arg2 + xxx,
> > sizeof(type)), which is neither elegant nor nice on the script author
> >
> > Because ''typedef struct { ... } network_mysqld_con''
is actually a non-
> > trivial struct and refers to various other structs and enums
it''s not
> > a good idea to copy it in. Things _will_ get out of sync.
> 
> 	At first glance, it seems like user space CTF would be a big
> win here.
Well, the easiest fix is to do one, or both, of fixing system headers to
be DTrace-friendly (hello, Solaris stat_impl.h), or improving the
DTrace parser to understand such headers and ignore the relevant bits

regards
john