> Hi everyone, > > I''ve been having a go at defining a userland provider, as it''s one of the > four things on Bryan''s initial list. I''ve taken most of my cues from the > plockstat provider Adam''s put into libc, and the makefiles around it; I > thought I''d document the process of defining a userland provider as I''ve > been doing it, as it might be useful to someone else out there. And, of > course, I''ve got a problem which I thought someone might be able to help > with. > > ... > > Having compiled this to t.o, I''d then invoke: > > dtrace -G -xlazyload -s b.d -o b.o t.o > > This creates b.o and fixes up t.o. It''s important to include all the object > files here so all those function calls get fixed up - if you look at the > makefiles in libc, you can see that Adam includes all the threads objects on > the command line. > > 6. Build your archive/binary from the objects. So in my example: > > cc -o a t.o b.o > > > ... and hey presto, you''ve got some probes you can enable: > > # dtrace -l -P foo\$target -c ./a > ID PROVIDER MODULE FUNCTION NAME > 29535 foo14420 a main bar > > But here''s the problem - although DTrace knows the probes are there, they > don''t seem to fire! For example... > > # dtrace -P foo\$target -c ./a > dtrace: description ''foo$target'' matched 1 probe > Hello world 0 > Hello world 1 > Hello world 2 > Hello world 3 > Hello world 4 > Hello world 5 > Hello world 6 > Hello world 7 > Hello world 8 > Hello world 9 > Hello world 0 > Hello world 1 > Hello world 2 > Hello world 3 > Hello world 4 > Hello world 5 > Hello world 6 > Hello world 7 > Hello world 8 > Hello world 9 > dtrace: pid 15369 has exited > > # > > Can anyone see where I''m going wrong? Anyone else had a go at this?Phil, This is the correct procedure, and this does work properly on the latest bits, unless I''m missing some aspect of your configuration. But Adam and I made a bunch of changes in this area in the late builds of S10, so perhaps there is a discrepancy there. What architecture and build of S10 are you on? Are you using the Sun compiler or gcc? Incidentally, for reference, the final version of the answerbook includes Chapter 34, "Statically Defined Tracing for User Applications", that describes the procedure (essentially the same as the part of the mail that I elided, except that typically you don''t need to use -xlazyload). -Mike -- Mike Shapiro, Solaris Kernel Development. _______________________________________________ DTrace mailing list DTrace@opensolaris.org https://www.opensolaris.org/mailman/listinfo/dtrace
Hi Mike, Thanks for that.> This is the correct procedure, and this does work properly on > the latest bits, > unless I''m missing some aspect of your configuration. But > Adam and I made a > bunch of changes in this area in the late builds of S10, so > perhaps there is a > discrepancy there. What architecture and build of S10 are > you on? Are you > using the Sun compiler or gcc?My environment''s not all that clean - it''s build 71 on Opteron with the Sun compiler, but with a few tweaks here and there to solve some issues. I''ll clean it up and see if things improve.> > Incidentally, for reference, the final version of the > answerbook includes > Chapter 34, "Statically Defined Tracing for User Applications", that > describes the procedure (essentially the same as the part of the mail > that I elided, except that typically you don''t need to use > -xlazyload).Oh, that''s embarrassing - really sorry about this, Mike, I should have looked on docs.sun.com first. Got to say, though, I''m fairly pleased the section in the doc wasn''t all that different to my mail! -- Philip Beevers Fidessa Infrastructure Development mailto:philip.beevers@fidessa.com phone: +44 1483 206571> -----Original Message----- > From: Michael Shapiro [mailto:mws@eng.sun.com] > Sent: 05 January 2005 02:56 > To: philip.beevers@fidessa.com > Cc: dtrace@opensolaris.org > Subject: Re: [DTrace] Userland providers > > > > Hi everyone, > > > > I''ve been having a go at defining a userland provider, as > it''s one of the > > four things on Bryan''s initial list. I''ve taken most of my > cues from the > > plockstat provider Adam''s put into libc, and the makefiles > around it; I > > thought I''d document the process of defining a userland > provider as I''ve > > been doing it, as it might be useful to someone else out > there. And, of > > course, I''ve got a problem which I thought someone might be > able to help > > with. > > > > ... > > > > Having compiled this to t.o, I''d then invoke: > > > > dtrace -G -xlazyload -s b.d -o b.o t.o > > > > This creates b.o and fixes up t.o. It''s important to > include all the object > > files here so all those function calls get fixed up - if > you look at the > > makefiles in libc, you can see that Adam includes all the > threads objects on > > the command line. > > > > 6. Build your archive/binary from the objects. So in my example: > > > > cc -o a t.o b.o > > > > > > ... and hey presto, you''ve got some probes you can enable: > > > > # dtrace -l -P foo\$target -c ./a > > ID PROVIDER MODULE > FUNCTION NAME > > 29535 foo14420 a > main bar > > > > But here''s the problem - although DTrace knows the probes > are there, they > > don''t seem to fire! For example... > > > > # dtrace -P foo\$target -c ./a > > dtrace: description ''foo$target'' matched 1 probe > > Hello world 0 > > Hello world 1 > > Hello world 2 > > Hello world 3 > > Hello world 4 > > Hello world 5 > > Hello world 6 > > Hello world 7 > > Hello world 8 > > Hello world 9 > > Hello world 0 > > Hello world 1 > > Hello world 2 > > Hello world 3 > > Hello world 4 > > Hello world 5 > > Hello world 6 > > Hello world 7 > > Hello world 8 > > Hello world 9 > > dtrace: pid 15369 has exited > > > > # > > > > Can anyone see where I''m going wrong? Anyone else had a go at this? > > Phil, > > This is the correct procedure, and this does work properly on > the latest bits, > unless I''m missing some aspect of your configuration. But > Adam and I made a > bunch of changes in this area in the late builds of S10, so > perhaps there is a > discrepancy there. What architecture and build of S10 are > you on? Are you > using the Sun compiler or gcc? > > Incidentally, for reference, the final version of the > answerbook includes > Chapter 34, "Statically Defined Tracing for User Applications", that > describes the procedure (essentially the same as the part of the mail > that I elided, except that typically you don''t need to use > -xlazyload). > > -Mike > > -- > Mike Shapiro, Solaris Kernel Development. >_______________________________________________ DTrace mailing list DTrace@opensolaris.org https://www.opensolaris.org/mailman/listinfo/dtrace
> Hi Mike, > > Thanks for that. > > > This is the correct procedure, and this does work properly on > > the latest bits, > > unless I''m missing some aspect of your configuration. But > > Adam and I made a > > bunch of changes in this area in the late builds of S10, so > > perhaps there is a > > discrepancy there. What architecture and build of S10 are > > you on? Are you > > using the Sun compiler or gcc? > > My environment''s not all that clean - it''s build 71 on Opteron with the Sun > compiler, but with a few tweaks here and there to solve some issues. I''ll > clean it up and see if things improve.If you''re trying to create and use userland SDT probes for a 64-bit Opteron program, you need to be using s10_73 or later. -Mike -- Mike Shapiro, Solaris Kernel Development. _______________________________________________ DTrace mailing list DTrace@opensolaris.org https://www.opensolaris.org/mailman/listinfo/dtrace
Hi everyone, I''ve been having a go at defining a userland provider, as it''s one of the four things on Bryan''s initial list. I''ve taken most of my cues from the plockstat provider Adam''s put into libc, and the makefiles around it; I thought I''d document the process of defining a userland provider as I''ve been doing it, as it might be useful to someone else out there. And, of course, I''ve got a problem which I thought someone might be able to help with. OK, so here''s how you define a userland DTrace provider: 1. Work out what your probes are, where they should be, and what their arguments are. Sounds obvious, but I suspect this will be pretty hard. Within the applications I work on, we have a whole host of statistics, and working out which statistics we should have and where they should be maintained is the toughest part. Anyway, I''m just testing, so I''ve skipped that step for now ;-) 2. Create a D script which defines your provider. Adam''s example for the plockstat provider is in the source tree at /usr/src/lib/libc/port/threads/plockstat.d. My example, defining a single probe called bar from a provider called foo with a couple of integer arguments, is: provider foo { probe bar(int a, int b) : (int a, int b); }; #pragma D attributes Evolving/Evolving/ISA provider foo provider #pragma D attributes Private/Private/Unknown provider foo module #pragma D attributes Private/Private/Unknown provider foo function #pragma D attributes Evolving/Evolving/ISA provider foo name #pragma D attributes Evolving/Evolving/ISA provider foo args This appears to define the probes you''re going to code up, and their stability attributes. 3. Write your code, using the preprocessor macros DTRACE_PROBE and DTRACE_PROBE1 to DTRACE_PROBE5 to define the points in the code at which the probes should fire. The first two args for all these macros are the provider and probe name - the DTRACE_PROBE1 - 5 probes allow you to specify 1 to 5 arguments to the probe. They''re all defined in /usr/include/sys/sdt.h. So, to follow my example, the code looks like: DTRACE_PROBE2(foo, bar, 1, 2); 4. Compile your code into object code format normally - but don''t link or build an archive just yet. [Note: you''ll spot the above macros compile down to calls to magic, extern''d functions which are unique to each probe. These don''t exist anywhere so your code won''t link into an executable anyway] 5. Wave the DTrace magic wand. This step compiles an object code file from the D script you created at step 2, and fixes up the objects you compiled in step 4 by removing the extern''d function calls. I guess it must record the offsets in the object code of the probe points somewhere, too, so DTrace knows where to enable probes at runtime. Anyway, you do this by invoking dtrace(1M) as follows: dtrace -G -xlazyload -s <D script name> -o <Object file name for output> <list of compiled objects> So, let''s say I put the D script from section 2 in a file b.d, and I''ve got a t.c which looks like this: #include <stdio.h> #include <unistd.h> #include <sys/sdt.h> int main(int argc, char** argv) { for (int i = 0; i < 10; i++) { printf("Hello world %d\n", i); DTRACE_PROBE2(foo, bar, 1, 2); } sleep(10); for (int i = 0; i < 10; i++) { printf("Hello world %d\n", i); DTRACE_PROBE2(foo, bar, 1, 2); } sleep(10); return (0); } Having compiled this to t.o, I''d then invoke: dtrace -G -xlazyload -s b.d -o b.o t.o This creates b.o and fixes up t.o. It''s important to include all the object files here so all those function calls get fixed up - if you look at the makefiles in libc, you can see that Adam includes all the threads objects on the command line. 6. Build your archive/binary from the objects. So in my example: cc -o a t.o b.o ... and hey presto, you''ve got some probes you can enable: # dtrace -l -P foo\$target -c ./a ID PROVIDER MODULE FUNCTION NAME 29535 foo14420 a main bar But here''s the problem - although DTrace knows the probes are there, they don''t seem to fire! For example... # dtrace -P foo\$target -c ./a dtrace: description ''foo$target'' matched 1 probe Hello world 0 Hello world 1 Hello world 2 Hello world 3 Hello world 4 Hello world 5 Hello world 6 Hello world 7 Hello world 8 Hello world 9 Hello world 0 Hello world 1 Hello world 2 Hello world 3 Hello world 4 Hello world 5 Hello world 6 Hello world 7 Hello world 8 Hello world 9 dtrace: pid 15369 has exited # Can anyone see where I''m going wrong? Anyone else had a go at this? -- Philip Beevers Fidessa Infrastructure Development mailto:philip.beevers@fidessa.com phone: +44 1483 206571 _______________________________________________ DTrace mailing list DTrace@opensolaris.org https://www.opensolaris.org/mailman/listinfo/dtrace