I can''t get probes with string/char* arguments to work in C++ and I wonder if I''m missing something obvious... (NB running snv_40 at the moment, so maybe I''m missing some recent fixes?) If my probe definition uses ''string'' like this: provider foo { probe foo(string); }; then the generated header for my probes refers to an undefined type ''string'': /usr/sbin/dtrace -h -s foo.d -o foo_probes.h /opt/SUNWspro/bin/CC -c foo.cxx -o foo.o "foo_probes.h", line 18: Error: string is not defined. if I define my probe with a char* argument instead, then everything builds fine but when I run with the following script: foo$target::: { printf("%-15s: %-15s\n", probename, stringof(args[0])); } I get an error: dtrace -s test.d -c ./bar dtrace: script ''test.d'' matched 1 probe Done. dtrace: pid 2610 has exited dtrace: error on enabled probe ID 1 (ID 51288: foo2610:bar:__1cDfoo6F_v_:foo): invalid address (0x12000) in action #2 Note that the probe invocation looks like this: const char* hello = "hello"; FOO_FOO((char*)hello); So, I''m guessing that using string rather than char* is what I want to do, but it looks as though the dtrace -h command isn''t handling string correctly...? This message posted from opensolaris.org
Sean McGrath - Sun Microsystems Ireland
2006-Sep-08 14:08 UTC
[dtrace-discuss] USDT in C++, string problems
Matt Stupple stated: < I can''t get probes with string/char* arguments to work in C++ and I wonder if I''m missing something obvious... (NB running snv_40 at the moment, so maybe I''m missing some recent fixes?) < < If my probe definition uses ''string'' like this: < < provider foo < { < probe foo(string); < }; < < then the generated header for my probes refers to an undefined type ''string'': < < /usr/sbin/dtrace -h -s foo.d -o foo_probes.h < /opt/SUNWspro/bin/CC -c foo.cxx -o foo.o < "foo_probes.h", line 18: Error: string is not defined. < < if I define my probe with a char* argument instead, then everything builds fine but when I run with the following script: < < foo$target::: < { < printf("%-15s: %-15s\n", probename, stringof(args[0])); < } You need to copy the string from the process/user space to kernel space with copyinstr(). See Chap. 33 on the dtrace guide: http://docs.sun.com/app/docs/doc/817-6223/6mlkidlmd?a=view The link will show you why you''re getting the ''invalid address'' error etc. Try: foo$target::: { printf("%-15s: %-15s\n", probename, stringof(copyinstr(arg0))); } I''ve done something like this already with beer and python at: http://blogs.sun.com/smg/entry/beer_python_and_stuff Where my provider is: provider python { probe pythond__2(int, string); }; and I can use it like: dtrace -o beer.out -n ''python$target:::pythond-2{@[stringof(copyinstr(arg1)), arg0]=count();}'' -c ''../../python beer.py 200'' Note the ''copyinstr'' there.. Hope this help.s Regards, Sean. . < < I get an error: < < dtrace -s test.d -c ./bar < dtrace: script ''test.d'' matched 1 probe < Done. < dtrace: pid 2610 has exited < dtrace: error on enabled probe ID 1 (ID 51288: foo2610:bar:__1cDfoo6F_v_:foo): invalid address (0x12000) in action #2 < < Note that the probe invocation looks like this: < < const char* hello = "hello"; < FOO_FOO((char*)hello); < < So, I''m guessing that using string rather than char* is what I want to do, but it looks as though the dtrace -h command isn''t handling string correctly...? < < < This message posted from opensolaris.org < _______________________________________________ < dtrace-discuss mailing list < dtrace-discuss at opensolaris.org -- Sean. .
> > You need to copy the string from the process/user > space to kernel space > with copyinstr(). See Chap. 33 on the dtrace guide: > http://docs.sun.com/app/docs/doc/817-6223/6mlkidlmd?a=view >Magic - so I *was* missing something obvious, and all is working fine now. Thanks, Matt. PS Am I right to think that the breakage in dtrace -h when using the ''string'' type rather than char* is a bug? This message posted from opensolaris.org
On Fri, Sep 08, 2006 at 07:17:08AM -0700, Matt Stupple wrote:> PS Am I right to think that the breakage in dtrace -h when using the > ''string'' type rather than char* is a bug?Arguably, but the header file should really use the type ''char *'' since string (presumably) is just the D datatype. Regardless of how it handles it, it could be a bit more graceful. Feel free to file a bug. Adam -- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl