Matthias Pfützner - Data Center Ambassador - Strategy and Technology
2006-Jan-12 09:25 UTC
[dtrace-discuss] Re: dtrace in my kernel module, what''s the problem?
It can''t be that chapter...
Because it starts:
The Statically Defined Tracing (SDT) provider creates probes at sites that a
software programmer has formally designated. The SDT mechanism allows
programmers to consciously choose locations of interest to users of DTrace and
to convey some semantic knowledge about each location through the probe name.
The Solaris kernel has defined a handful of SDT probes, and will likely add more
over time. DTrace also provides a mechanism for user application developers to
define static probes, described in Chapter 34, Statically Defined Tracing for
User Applications.
Still curious (and now, for the first time to the dtrace-alias),
Matthias
I (Matthias Pf?tzner - Data Center Ambassador - Strategy and Technology)
wrote:> Adam,
>
> the problem is clear to me, but i didn''t find the kernel
chapter... ;-)
>
> Here''s the TOC:
>
> * Index
> * Book Information
> * Preface
> * 1. Introduction
> * 2. Types, Operators, and Expressions
> * 3. Variables
> * 4. D Program Structure
> * 5. Pointers and Arrays
> * 6. Strings
> * 7. Structs and Unions
> * 8. Type and Constant Definitions
> * 9. Aggregations
> * 10. Actions and Subroutines
> * 11. Buffers and Buffering
> * 12. Output Formatting
> * 13. Speculative Tracing
> * 14. dtrace(1M) Utility
> * 15. Scripting
> * 16. Options and Tunables
> * 17. dtrace Provider
> * 18. lockstat Provider
> * 19. profile Provider
> * 20. fbt Provider
> * 21. syscall Provider
> * 22. sdt Provider
> * 23. sysinfo Provider
> * 24. vminfo Provider
> * 25. proc Provider
> * 26. sched Provider
> * 27. io Provider
> * 28. mib Provider
> * 29. fpuinfo Provider
> * 30. pid Provider
> * 31. plockstat Provider
> * 32. fasttrap Provider
> * 33. User Process Tracing
> * 34. Statically Defined Tracing for User Applications
> * 35. Security
> * 36. Anonymous Tracing
> * 37. Postmortem Tracing
> * 38. Performance Considerations
> * 39. Stability
> * 40. Translators
> * 41. Versioning
> * Glossary
>
> Which chapter is the kernel tracing developing "info-container"?
The "sdt"
> chapter, aka chapter 22?
>
> Still curious...
>
> Matthias
>
> You (Adam Leventhal) write:
> > Hi Matthias,
> >
> > Please post this question to dtrace-discuss at opensolaris.org, but
the short
> > answer is that USDT is just for _user_ land binaries; for (kernel) SDT
> > check that chapter in the Solaris Dynamic Tracing Guide.
> >
> > Adam
> >
> > On Wed, Jan 11, 2006 at 09:46:45PM +0100, Matthias Pftzner - Data
Center Ambassador - Strategy and Technology wrote:
> > > Folks,
> > >
> > > I try to add dtrace points to "my" kernel module, but
do get errors during
> > > the compile.
> > >
> > > /usr/sbin/dtrace -G -32 -s saa713xdtrace.d
obj-i386/saa713x-core.o obj-i386/saa713x-video.o obj-i386/saa713x-cards.o
obj-i386/saa713x-tvaudio.o obj-i386/saa713x-i2c.o
> > > dtrace: failed to link script saa713xdtrace: an error was
encountered while processing obj-i386/saa713x-core.o
> > >
> > > Here''s the code:
> > >
> > > bash-3.00$ cat saa713xdtrace.d
> > > provider saa713xdtrace {
> > > probe routine__enter(string);
> > > probe routine__exit(string);
> > > };
> > > bash-3.00$
> > >
> > > And in the file saa713x-core.c I do have:
> > >
> > > #include <sys/sdt.h>
> > >
> > > void saa713x_print_ioctl(char *name, unsigned int cmd)
> > > {
> > > const char *cmdnm;
> > > char *dir = "??";
> > >
> > > DTRACE_PROBE1(saa713xdtrace, routine__enter,
"saa713x_print_ioctl");
> > > /*
> > > * IOR/read == IOC_OUT == kernel->user
> > > * IOW/write == IOC_IN == user->kernel
> > > */
> > > switch (cmd & IOC_INOUT) {
> > >
> > > et.al...
> > >
> > > So, what''s the problem, the error message isn''t
really helpful... ;-(
> > >
> > > All infos I found on this stuff is in:
> > >
> > >
http://docs.sun.com/app/docs/doc/817-6223/6mlkidlms?a=view
> > >
> > > Is there more? I did not find anything under:
> > >
> > > http://www.sun.com/bigadmin/content/dtrace/
> > >
> > > Clueless,
> > > Matthias
> > > --
> > >
***********************************************************************
> > > Matthias Pf?tzner
> > > Data Center Ambassador
> > > Strategy & Technology
> > > Sun Microsystems GmbH Tel: +49 6103 752-394
(x65394)
> > > Amp?restra?e 6 Mobile: +49 172 8428766
> > > 63225 Langen Fax: +49 6103 752-167
> > > Germany mailto:Matthias.Pfuetzner
at Sun.COM
> > >
***********************************************************************
> >
> > --
> > Adam Leventhal, Solaris Kernel Development
http://blogs.sun.com/ahl
>
> --
> ***********************************************************************
> Matthias Pf?tzner
> Data Center Ambassador
> Strategy & Technology
> Sun Microsystems GmbH Tel: +49 6103 752-394 (x65394)
> Amp?restra?e 6 Mobile: +49 172 8428766
> 63225 Langen Fax: +49 6103 752-167
> Germany mailto:Matthias.Pfuetzner at Sun.COM
> ***********************************************************************
--
***********************************************************************
Matthias Pf?tzner
Data Center Ambassador
Strategy & Technology
Sun Microsystems GmbH Tel: +49 6103 752-394 (x65394)
Amp?restra?e 6 Mobile: +49 172 8428766
63225 Langen Fax: +49 6103 752-167
Germany mailto:Matthias.Pfuetzner at Sun.COM
***********************************************************************
Matthias Pfützner - Data Center Ambassador - Strategy and Technology
2006-Jan-12 12:25 UTC
[dtrace-discuss] Re: dtrace in my kernel module, what''s the problem?
Perhaps I need to ask the question differently:
What do I need to do to enable a kernel driver to be dtrace-able?
Aka: What code do I need to put into the kernel driver source, so that it
becomes accessable via dtrace?
I already learned, that my kernel driver will not become a new provider,
that''s OK.
I already learned, that i need to "somehow register" my variables,
routines,
whatever to be "seen" by the dtrace kernel stuff...
So, a "HowTo" for driver developpers might be helpful! (As I have been
searching now for hours, but didn''t find any easy to follow guidelines
yet... ;-( )
Matthias
I (Matthias Pf?tzner - Data Center Ambassador - Strategy and Technology)
wrote:> It can''t be that chapter...
>
> Because it starts:
>
> The Statically Defined Tracing (SDT) provider creates probes at sites that
a software programmer has formally designated. The SDT mechanism allows
programmers to consciously choose locations of interest to users of DTrace and
to convey some semantic knowledge about each location through the probe name.
The Solaris kernel has defined a handful of SDT probes, and will likely add more
over time. DTrace also provides a mechanism for user application developers to
define static probes, described in Chapter 34, Statically Defined Tracing for
User Applications.
>
> Still curious (and now, for the first time to the dtrace-alias),
> Matthias
>
> I (Matthias Pf?tzner - Data Center Ambassador - Strategy and Technology)
wrote:
> > Adam,
> >
> > the problem is clear to me, but i didn''t find the kernel
chapter... ;-)
> >
> > Here''s the TOC:
> >
> > * Index
> > * Book Information
> > * Preface
> > * 1. Introduction
> > * 2. Types, Operators, and Expressions
> > * 3. Variables
> > * 4. D Program Structure
> > * 5. Pointers and Arrays
> > * 6. Strings
> > * 7. Structs and Unions
> > * 8. Type and Constant Definitions
> > * 9. Aggregations
> > * 10. Actions and Subroutines
> > * 11. Buffers and Buffering
> > * 12. Output Formatting
> > * 13. Speculative Tracing
> > * 14. dtrace(1M) Utility
> > * 15. Scripting
> > * 16. Options and Tunables
> > * 17. dtrace Provider
> > * 18. lockstat Provider
> > * 19. profile Provider
> > * 20. fbt Provider
> > * 21. syscall Provider
> > * 22. sdt Provider
> > * 23. sysinfo Provider
> > * 24. vminfo Provider
> > * 25. proc Provider
> > * 26. sched Provider
> > * 27. io Provider
> > * 28. mib Provider
> > * 29. fpuinfo Provider
> > * 30. pid Provider
> > * 31. plockstat Provider
> > * 32. fasttrap Provider
> > * 33. User Process Tracing
> > * 34. Statically Defined Tracing for User Applications
> > * 35. Security
> > * 36. Anonymous Tracing
> > * 37. Postmortem Tracing
> > * 38. Performance Considerations
> > * 39. Stability
> > * 40. Translators
> > * 41. Versioning
> > * Glossary
> >
> > Which chapter is the kernel tracing developing
"info-container"? The "sdt"
> > chapter, aka chapter 22?
> >
> > Still curious...
> >
> > Matthias
> >
> > You (Adam Leventhal) write:
> > > Hi Matthias,
> > >
> > > Please post this question to dtrace-discuss at opensolaris.org,
but the short
> > > answer is that USDT is just for _user_ land binaries; for
(kernel) SDT
> > > check that chapter in the Solaris Dynamic Tracing Guide.
> > >
> > > Adam
> > >
> > > On Wed, Jan 11, 2006 at 09:46:45PM +0100, Matthias Pftzner - Data
Center Ambassador - Strategy and Technology wrote:
> > > > Folks,
> > > >
> > > > I try to add dtrace points to "my" kernel module,
but do get errors during
> > > > the compile.
> > > >
> > > > /usr/sbin/dtrace -G -32 -s saa713xdtrace.d
obj-i386/saa713x-core.o obj-i386/saa713x-video.o obj-i386/saa713x-cards.o
obj-i386/saa713x-tvaudio.o obj-i386/saa713x-i2c.o
> > > > dtrace: failed to link script saa713xdtrace: an
error was encountered while processing obj-i386/saa713x-core.o
> > > >
> > > > Here''s the code:
> > > >
> > > > bash-3.00$ cat saa713xdtrace.d
> > > > provider saa713xdtrace {
> > > > probe routine__enter(string);
> > > > probe routine__exit(string);
> > > > };
> > > > bash-3.00$
> > > >
> > > > And in the file saa713x-core.c I do have:
> > > >
> > > > #include <sys/sdt.h>
> > > >
> > > > void saa713x_print_ioctl(char *name, unsigned int cmd)
> > > > {
> > > > const char *cmdnm;
> > > > char *dir = "??";
> > > >
> > > > DTRACE_PROBE1(saa713xdtrace, routine__enter,
"saa713x_print_ioctl");
> > > > /*
> > > > * IOR/read == IOC_OUT == kernel->user
> > > > * IOW/write == IOC_IN == user->kernel
> > > > */
> > > > switch (cmd & IOC_INOUT) {
> > > >
> > > > et.al...
> > > >
> > > > So, what''s the problem, the error message
isn''t really helpful... ;-(
> > > >
> > > > All infos I found on this stuff is in:
> > > >
> > > >
http://docs.sun.com/app/docs/doc/817-6223/6mlkidlms?a=view
> > > >
> > > > Is there more? I did not find anything under:
> > > >
> > > > http://www.sun.com/bigadmin/content/dtrace/
> > > >
> > > > Clueless,
> > > > Matthias
> > > > --
> > > >
***********************************************************************
> > > > Matthias Pf?tzner
> > > > Data Center Ambassador
> > > > Strategy & Technology
> > > > Sun Microsystems GmbH Tel: +49 6103 752-394
(x65394)
> > > > Amp?restra?e 6 Mobile: +49 172
8428766
> > > > 63225 Langen Fax: +49 6103 752-167
> > > > Germany
mailto:Matthias.Pfuetzner at Sun.COM
> > > >
***********************************************************************
> > >
> > > --
> > > Adam Leventhal, Solaris Kernel Development
http://blogs.sun.com/ahl
> >
> > --
> >
***********************************************************************
> > Matthias Pf?tzner
> > Data Center Ambassador
> > Strategy & Technology
> > Sun Microsystems GmbH Tel: +49 6103 752-394 (x65394)
> > Amp?restra?e 6 Mobile: +49 172 8428766
> > 63225 Langen Fax: +49 6103 752-167
> > Germany mailto:Matthias.Pfuetzner at
Sun.COM
> >
***********************************************************************
>
> --
> ***********************************************************************
> Matthias Pf?tzner
> Data Center Ambassador
> Strategy & Technology
> Sun Microsystems GmbH Tel: +49 6103 752-394 (x65394)
> Amp?restra?e 6 Mobile: +49 172 8428766
> 63225 Langen Fax: +49 6103 752-167
> Germany mailto:Matthias.Pfuetzner at Sun.COM
> ***********************************************************************
--
***********************************************************************
Matthias Pf?tzner
Data Center Ambassador
Strategy & Technology
Sun Microsystems GmbH Tel: +49 6103 752-394 (x65394)
Amp?restra?e 6 Mobile: +49 172 8428766
63225 Langen Fax: +49 6103 752-167
Germany mailto:Matthias.Pfuetzner at Sun.COM
***********************************************************************
Matthias Pfützner - Data Center Ambassador - Strategy and Technology
2006-Jan-12 13:02 UTC
[dtrace-discuss] Re: dtrace in my kernel module, what''s the problem?
On on this topic...
I found:
http://www.opensolaris.org/jive/thread.jspa?threadID=1391&tstart=210
but that still misses stuff for me to understand it completely.
a.) Do I need to LINK (ld) something to the binaries?
b.) Can I create own new probes? (If so, how?)
Because the section in the docs is WAY TO BRIEF (aka, no examples!):
Creating SDT Probes
If you are a device driver developer, you might be interested in creating your
own SDT probes in your Solaris driver. The disabled probe effect of SDT is
essentially the cost of several no-operation machine instructions. You are
therefore encouraged to add SDT probes to your device drivers as needed. Unless
these probes negatively affect performance, you can leave them in your shipping
code.
Declaring Probes
SDT probes are declared using the DTRACE_PROBE, DTRACE_PROBE1, DTRACE_PROBE2,
DTRACE_PROBE3 and DTRACE_PROBE4 macros from <sys/sdt.h>. The module name
and function name of an SDT-based probe corresponds to the kernel module and
function of the probe. The name of the probe depends on the name given in the
DTRACE_PROBEn macro. If the name contains no two consecutive underbars (__), the
name of the probe is as written in the macro. If the name contains any two
consecutive underbars, the probe name converts the consecutive underbars to a
single dash (-). For example, if a DTRACE_PROBE macro specifies
transaction__start, the SDT probe will be named transaction-start. This
substitution allows C code to provide macro names that are not valid C
identifiers without specifying a string.
DTrace includes the kernel module name and function name as part of the tuple
identifying a probe, so you do not need to include this information in the probe
name to prevent name space collisions. You can use the command dtrace -l -P sdt
-m module on your driver module to list the probes you have installed and the
full names that will be seen by users of DTrace.
Probe Arguments
The arguments for each SDT probe are the arguments specified in the
corresponding DTRACE_PROBEn macro reference. The number of arguments depends on
which macro was used to create the probe: DTRACE_PROBE1 specifies one argument,
DTRACE_PROBE2 specifies two arguments, and so on. When declaring your SDT
probes, you can minimize their disabled probe effect by not dereferencing
pointers and not loading from global variables in the probe arguments. Both
pointer dereferencing and global variable loading may be done safely in D
actions that enable probes, so DTrace users can request these actions only when
they are needed.
And: The section on "Declaring Probes" only states:
The module name and function name of an SDT-based probe corresponds to the
kernel module and function of the probe. The name of the probe depends on the
name given in the DTRACE_PROBEn macro.
Which probes are allowed?
And, looking at the SDT probes, there are only 4:
callout-start
callout-end
interrupt-start
interrupt-complete
That''s not really, what I''m looking for (or thinking a doc
should look
like)...
Looking at the nvidia driver, it has something like 40000 probes based on the
FBT provider, but the doc to the FBT provider is even more brief, than the sdt
docs... (will say, the is NO docu on how to register my driver with the fgt
provider...)
You see, the dtrace docs et.al. are all very think, but do cover only the
"end-user" side very well. It does NOT yet help kernel/driver
developpers very
well... ;-(
So, still: I need help!
Matthias
I (Matthias Pf?tzner - Data Center Ambassador - Strategy and Technology)
wrote:> Perhaps I need to ask the question differently:
>
> What do I need to do to enable a kernel driver to be dtrace-able?
>
> Aka: What code do I need to put into the kernel driver source, so that it
> becomes accessable via dtrace?
>
> I already learned, that my kernel driver will not become a new provider,
> that''s OK.
>
> I already learned, that i need to "somehow register" my
variables, routines,
> whatever to be "seen" by the dtrace kernel stuff...
>
> So, a "HowTo" for driver developpers might be helpful! (As I have
been
> searching now for hours, but didn''t find any easy to follow
guidelines
> yet... ;-( )
>
> Matthias
>
> I (Matthias Pf?tzner - Data Center Ambassador - Strategy and Technology)
wrote:
> > It can''t be that chapter...
> >
> > Because it starts:
> >
> > The Statically Defined Tracing (SDT) provider creates probes at sites
that a software programmer has formally designated. The SDT mechanism allows
programmers to consciously choose locations of interest to users of DTrace and
to convey some semantic knowledge about each location through the probe name.
The Solaris kernel has defined a handful of SDT probes, and will likely add more
over time. DTrace also provides a mechanism for user application developers to
define static probes, described in Chapter 34, Statically Defined Tracing for
User Applications.
> >
> > Still curious (and now, for the first time to the dtrace-alias),
> > Matthias
> >
> > I (Matthias Pf?tzner - Data Center Ambassador - Strategy and
Technology) wrote:
> > > Adam,
> > >
> > > the problem is clear to me, but i didn''t find the kernel
chapter... ;-)
> > >
> > > Here''s the TOC:
> > >
> > > * Index
> > > * Book Information
> > > * Preface
> > > * 1. Introduction
> > > * 2. Types, Operators, and Expressions
> > > * 3. Variables
> > > * 4. D Program Structure
> > > * 5. Pointers and Arrays
> > > * 6. Strings
> > > * 7. Structs and Unions
> > > * 8. Type and Constant Definitions
> > > * 9. Aggregations
> > > * 10. Actions and Subroutines
> > > * 11. Buffers and Buffering
> > > * 12. Output Formatting
> > > * 13. Speculative Tracing
> > > * 14. dtrace(1M) Utility
> > > * 15. Scripting
> > > * 16. Options and Tunables
> > > * 17. dtrace Provider
> > > * 18. lockstat Provider
> > > * 19. profile Provider
> > > * 20. fbt Provider
> > > * 21. syscall Provider
> > > * 22. sdt Provider
> > > * 23. sysinfo Provider
> > > * 24. vminfo Provider
> > > * 25. proc Provider
> > > * 26. sched Provider
> > > * 27. io Provider
> > > * 28. mib Provider
> > > * 29. fpuinfo Provider
> > > * 30. pid Provider
> > > * 31. plockstat Provider
> > > * 32. fasttrap Provider
> > > * 33. User Process Tracing
> > > * 34. Statically Defined Tracing for User Applications
> > > * 35. Security
> > > * 36. Anonymous Tracing
> > > * 37. Postmortem Tracing
> > > * 38. Performance Considerations
> > > * 39. Stability
> > > * 40. Translators
> > > * 41. Versioning
> > > * Glossary
> > >
> > > Which chapter is the kernel tracing developing
"info-container"? The "sdt"
> > > chapter, aka chapter 22?
> > >
> > > Still curious...
> > >
> > > Matthias
> > >
> > > You (Adam Leventhal) write:
> > > > Hi Matthias,
> > > >
> > > > Please post this question to dtrace-discuss at
opensolaris.org, but the short
> > > > answer is that USDT is just for _user_ land binaries; for
(kernel) SDT
> > > > check that chapter in the Solaris Dynamic Tracing Guide.
> > > >
> > > > Adam
> > > >
> > > > On Wed, Jan 11, 2006 at 09:46:45PM +0100, Matthias Pftzner -
Data Center Ambassador - Strategy and Technology wrote:
> > > > > Folks,
> > > > >
> > > > > I try to add dtrace points to "my" kernel
module, but do get errors during
> > > > > the compile.
> > > > >
> > > > > /usr/sbin/dtrace -G -32 -s saa713xdtrace.d
obj-i386/saa713x-core.o obj-i386/saa713x-video.o obj-i386/saa713x-cards.o
obj-i386/saa713x-tvaudio.o obj-i386/saa713x-i2c.o
> > > > > dtrace: failed to link script saa713xdtrace: an
error was encountered while processing obj-i386/saa713x-core.o
> > > > >
> > > > > Here''s the code:
> > > > >
> > > > > bash-3.00$ cat saa713xdtrace.d
> > > > > provider saa713xdtrace {
> > > > > probe routine__enter(string);
> > > > > probe routine__exit(string);
> > > > > };
> > > > > bash-3.00$
> > > > >
> > > > > And in the file saa713x-core.c I do have:
> > > > >
> > > > > #include <sys/sdt.h>
> > > > >
> > > > > void saa713x_print_ioctl(char *name, unsigned int cmd)
> > > > > {
> > > > > const char *cmdnm;
> > > > > char *dir = "??";
> > > > >
> > > > > DTRACE_PROBE1(saa713xdtrace, routine__enter,
"saa713x_print_ioctl");
> > > > > /*
> > > > > * IOR/read == IOC_OUT == kernel->user
> > > > > * IOW/write == IOC_IN == user->kernel
> > > > > */
> > > > > switch (cmd & IOC_INOUT) {
> > > > >
> > > > > et.al...
> > > > >
> > > > > So, what''s the problem, the error message
isn''t really helpful... ;-(
> > > > >
> > > > > All infos I found on this stuff is in:
> > > > >
> > > > >
http://docs.sun.com/app/docs/doc/817-6223/6mlkidlms?a=view
> > > > >
> > > > > Is there more? I did not find anything under:
> > > > >
> > > > > http://www.sun.com/bigadmin/content/dtrace/
> > > > >
> > > > > Clueless,
> > > > > Matthias
> > > > > --
> > > > >
***********************************************************************
> > > > > Matthias Pf?tzner
> > > > > Data Center Ambassador
> > > > > Strategy & Technology
> > > > > Sun Microsystems GmbH Tel: +49 6103
752-394 (x65394)
> > > > > Amp?restra?e 6 Mobile: +49 172
8428766
> > > > > 63225 Langen Fax: +49 6103
752-167
> > > > > Germany
mailto:Matthias.Pfuetzner at Sun.COM
> > > > >
***********************************************************************
> > > >
> > > > --
> > > > Adam Leventhal, Solaris Kernel Development
http://blogs.sun.com/ahl
> > >
> > > --
> > >
***********************************************************************
> > > Matthias Pf?tzner
> > > Data Center Ambassador
> > > Strategy & Technology
> > > Sun Microsystems GmbH Tel: +49 6103 752-394
(x65394)
> > > Amp?restra?e 6 Mobile: +49 172 8428766
> > > 63225 Langen Fax: +49 6103 752-167
> > > Germany mailto:Matthias.Pfuetzner
at Sun.COM
> > >
***********************************************************************
> >
> > --
> >
***********************************************************************
> > Matthias Pf?tzner
> > Data Center Ambassador
> > Strategy & Technology
> > Sun Microsystems GmbH Tel: +49 6103 752-394 (x65394)
> > Amp?restra?e 6 Mobile: +49 172 8428766
> > 63225 Langen Fax: +49 6103 752-167
> > Germany mailto:Matthias.Pfuetzner at
Sun.COM
> >
***********************************************************************
>
> --
> ***********************************************************************
> Matthias Pf?tzner
> Data Center Ambassador
> Strategy & Technology
> Sun Microsystems GmbH Tel: +49 6103 752-394 (x65394)
> Amp?restra?e 6 Mobile: +49 172 8428766
> 63225 Langen Fax: +49 6103 752-167
> Germany mailto:Matthias.Pfuetzner at Sun.COM
> ***********************************************************************
--
***********************************************************************
Matthias Pf?tzner
Data Center Ambassador
Strategy & Technology
Sun Microsystems GmbH Tel: +49 6103 752-394 (x65394)
Amp?restra?e 6 Mobile: +49 172 8428766
63225 Langen Fax: +49 6103 752-167
Germany mailto:Matthias.Pfuetzner at Sun.COM
***********************************************************************
Casper.Dik at Sun.COM
2006-Jan-12 13:07 UTC
[dtrace-discuss] Re: dtrace in my kernel module, what''s the problem?
>a.) Do I need to LINK (ld) something to the binaries?No.>b.) Can I create own new probes? (If so, how?)Yes, by using DTRACE_PROBEXXX>Looking at the nvidia driver, it has something like 40000 probes based on the >FBT provider, but the doc to the FBT provider is even more brief, than the sdt >docs... (will say, the is NO docu on how to register my driver with the fgt >provider...)The FBT probes are generated automatically for each function entry/exit point. Casper
Matthias Pfützner - Data Center Ambassador - Strategy and Technology
2006-Jan-12 13:14 UTC
[dtrace-discuss] Re: dtrace in my kernel module, what''s the problem?
Thanks, Casper, I might be stubbornly dump, but: You (Casper.Dik at Sun.COM) write:> > >a.) Do I need to LINK (ld) something to the binaries? > > No. > > >b.) Can I create own new probes? (If so, how?) > > Yes, by using DTRACE_PROBEXXXHOW? By simply adding a probe (but where do I define that probe?)? The DTRACE_PROBEX() has a PROBENAME as first argument. I do assume, that probename must be defined SOMEWHERE? Or am I totally wrong on that?> >Looking at the nvidia driver, it has something like 40000 probes based on the > >FBT provider, but the doc to the FBT provider is even more brief, than the sdt > >docs... (will say, the is NO docu on how to register my driver with the fgt > >provider...) > > The FBT probes are generated automatically for each function entry/exit point.So, any kernel driver will get these? Cool! As you see, I''m still not that knowledgable about the dtrace stuff... ;-(> CasperMatthias -- *********************************************************************** Matthias Pf?tzner Data Center Ambassador Strategy & Technology Sun Microsystems GmbH Tel: +49 6103 752-394 (x65394) Amp?restra?e 6 Mobile: +49 172 8428766 63225 Langen Fax: +49 6103 752-167 Germany mailto:Matthias.Pfuetzner at Sun.COM ***********************************************************************
Casper.Dik at Sun.COM
2006-Jan-12 13:15 UTC
[dtrace-discuss] Re: dtrace in my kernel module, what''s the problem?
>The DTRACE_PROBEX() has a PROBENAME as first argument. I do assume, that >probename must be defined SOMEWHERE? Or am I totally wrong on that?You make it up.>> The FBT probes are generated automatically for each function entry/exit point. > >So, any kernel driver will get these? Cool!yes; and if you use the "ctf" tools on them you''ll get the type information also. Casper
Roch Bourbonnais - Performance Engineering
2006-Jan-13 10:40 UTC
[dtrace-discuss] Re: dtrace in my kernel module, what''s the problem?
<Sorry If missed a previous answer here;>
It seems that your just getting fooled by the amazing design
of dtrace. If you have a kernel driver and you want to
dtrace into some of it''s functions you need not do anything.
Compile your driver (with whatever compiler suits you).
Install and load into a dtrace enabled kernel.
All your functions* are now instrumentable with dtrace:
dtrace -n
''fbt::saa713x_print_ioctl:entry{@a[stack(20)]=count()}''
-----------------------------------------
* some hand crafted assembly will not be.
If you want DTRACE to know the types of the arguments to your
functions then you need to run ctf on your driver but that''s
not mandatory; You still have access to the arguments but
you need to cast them to proper types in your d-scripts.
if you want DTRACE probe point somewhere which is not at a
function boundary then you need to use the DTRACE_PROBEX()
(and #include <sys/sdt.h>). Then insert in you code:
DTRACE_PROBE(myprobe)
That would show (once the driver is loaded) as
dtrace -n ''sdt:::myprobe{}''
If you use myprobe in multiple functions; it will show up as
multiple probes to dtrace:
dtrace -n ''sdt::f1:myprobe{}'' -n
''sdt::f2:myprobe{}''
HTH
-r
Matthias Pf?tzne r - Data Center Ambassador - Strategy and Technology writes:
> Perhaps I need to ask the question differently:
>
> What do I need to do to enable a kernel driver to be dtrace-able?
>
> Aka: What code do I need to put into the kernel driver source, so that it
> becomes accessable via dtrace?
>
> I already learned, that my kernel driver will not become a new provider,
> that''s OK.
>
> I already learned, that i need to "somehow register" my
variables, routines,
> whatever to be "seen" by the dtrace kernel stuff...
>
> So, a "HowTo" for driver developpers might be helpful! (As I
have been
> searching now for hours, but didn''t find any easy to follow
guidelines
> yet... ;-( )
>
> Matthias
>
> I (Matthias Pf?tzner - Data Center Ambassador - Strategy and Technology)
wrote:
> > It can''t be that chapter...
> >
> > Because it starts:
> >
> > The Statically Defined Tracing (SDT) provider creates probes at sites
that a software programmer has formally designated. The SDT mechanism allows
programmers to consciously choose locations of interest to users of DTrace and
to convey some semantic knowledge about each location through the probe name.
The Solaris kernel has defined a handful of SDT probes, and will likely add more
over time. DTrace also provides a mechanism for user application developers to
define static probes, described in Chapter 34, Statically Defined Tracing for
User Applications.
> >
> > Still curious (and now, for the first time to the dtrace-alias),
> > Matthias
> >
> > I (Matthias Pf?tzner - Data Center Ambassador - Strategy and
Technology) wrote:
> > > Adam,
> > >
> > > the problem is clear to me, but i didn''t find the
kernel chapter... ;-)
> > >
> > > Here''s the TOC:
> > >
> > > * Index
> > > * Book Information
> > > * Preface
> > > * 1. Introduction
> > > * 2. Types, Operators, and Expressions
> > > * 3. Variables
> > > * 4. D Program Structure
> > > * 5. Pointers and Arrays
> > > * 6. Strings
> > > * 7. Structs and Unions
> > > * 8. Type and Constant Definitions
> > > * 9. Aggregations
> > > * 10. Actions and Subroutines
> > > * 11. Buffers and Buffering
> > > * 12. Output Formatting
> > > * 13. Speculative Tracing
> > > * 14. dtrace(1M) Utility
> > > * 15. Scripting
> > > * 16. Options and Tunables
> > > * 17. dtrace Provider
> > > * 18. lockstat Provider
> > > * 19. profile Provider
> > > * 20. fbt Provider
> > > * 21. syscall Provider
> > > * 22. sdt Provider
> > > * 23. sysinfo Provider
> > > * 24. vminfo Provider
> > > * 25. proc Provider
> > > * 26. sched Provider
> > > * 27. io Provider
> > > * 28. mib Provider
> > > * 29. fpuinfo Provider
> > > * 30. pid Provider
> > > * 31. plockstat Provider
> > > * 32. fasttrap Provider
> > > * 33. User Process Tracing
> > > * 34. Statically Defined Tracing for User Applications
> > > * 35. Security
> > > * 36. Anonymous Tracing
> > > * 37. Postmortem Tracing
> > > * 38. Performance Considerations
> > > * 39. Stability
> > > * 40. Translators
> > > * 41. Versioning
> > > * Glossary
> > >
> > > Which chapter is the kernel tracing developing
"info-container"? The "sdt"
> > > chapter, aka chapter 22?
> > >
> > > Still curious...
> > >
> > > Matthias
> > >
> > > You (Adam Leventhal) write:
> > > > Hi Matthias,
> > > >
> > > > Please post this question to dtrace-discuss at
opensolaris.org, but the short
> > > > answer is that USDT is just for _user_ land binaries; for
(kernel) SDT
> > > > check that chapter in the Solaris Dynamic Tracing Guide.
> > > >
> > > > Adam
> > > >
> > > > On Wed, Jan 11, 2006 at 09:46:45PM +0100, Matthias Pftzner
- Data Center Ambassador - Strategy and Technology wrote:
> > > > > Folks,
> > > > >
> > > > > I try to add dtrace points to "my" kernel
module, but do get errors during
> > > > > the compile.
> > > > >
> > > > > /usr/sbin/dtrace -G -32 -s saa713xdtrace.d
obj-i386/saa713x-core.o obj-i386/saa713x-video.o obj-i386/saa713x-cards.o
obj-i386/saa713x-tvaudio.o obj-i386/saa713x-i2c.o
> > > > > dtrace: failed to link script saa713xdtrace:
an error was encountered while processing obj-i386/saa713x-core.o
> > > > >
> > > > > Here''s the code:
> > > > >
> > > > > bash-3.00$ cat saa713xdtrace.d
> > > > > provider saa713xdtrace {
> > > > > probe routine__enter(string);
> > > > > probe routine__exit(string);
> > > > > };
> > > > > bash-3.00$
> > > > >
> > > > > And in the file saa713x-core.c I do have:
> > > > >
> > > > > #include <sys/sdt.h>
> > > > >
> > > > > void saa713x_print_ioctl(char *name, unsigned int cmd)
> > > > > {
> > > > > const char *cmdnm;
> > > > > char *dir = "??";
> > > > >
> > > > > DTRACE_PROBE1(saa713xdtrace, routine__enter,
"saa713x_print_ioctl");
> > > > > /*
> > > > > * IOR/read == IOC_OUT == kernel->user
> > > > > * IOW/write == IOC_IN == user->kernel
> > > > > */
> > > > > switch (cmd & IOC_INOUT) {
> > > > >
> > > > > et.al...
> > > > >
> > > > > So, what''s the problem, the error message
isn''t really helpful... ;-(
> > > > >
> > > > > All infos I found on this stuff is in:
> > > > >
> > > > >
http://docs.sun.com/app/docs/doc/817-6223/6mlkidlms?a=view
> > > > >
> > > > > Is there more? I did not find anything under:
> > > > >
> > > > > http://www.sun.com/bigadmin/content/dtrace/
> > > > >
> > > > > Clueless,
> > > > > Matthias
> > > > > --
> > > > >
***********************************************************************
> > > > > Matthias Pf?tzner
> > > > > Data Center Ambassador
> > > > > Strategy & Technology
> > > > > Sun Microsystems GmbH Tel: +49 6103
752-394 (x65394)
> > > > > Amp?restra?e 6 Mobile: +49 172
8428766
> > > > > 63225 Langen Fax: +49 6103
752-167
> > > > > Germany
mailto:Matthias.Pfuetzner at Sun.COM
> > > > >
***********************************************************************
> > > >
> > > > --
> > > > Adam Leventhal, Solaris Kernel Development
http://blogs.sun.com/ahl
> > >
> > > --
> > >
***********************************************************************
> > > Matthias Pf?tzner
> > > Data Center Ambassador
> > > Strategy & Technology
> > > Sun Microsystems GmbH Tel: +49 6103 752-394
(x65394)
> > > Amp?restra?e 6 Mobile: +49 172 8428766
> > > 63225 Langen Fax: +49 6103 752-167
> > > Germany mailto:Matthias.Pfuetzner
at Sun.COM
> > >
***********************************************************************
> >
> > --
> >
***********************************************************************
> > Matthias Pf?tzner
> > Data Center Ambassador
> > Strategy & Technology
> > Sun Microsystems GmbH Tel: +49 6103 752-394 (x65394)
> > Amp?restra?e 6 Mobile: +49 172 8428766
> > 63225 Langen Fax: +49 6103 752-167
> > Germany mailto:Matthias.Pfuetzner at
Sun.COM
> >
***********************************************************************
>
> --
> ***********************************************************************
> Matthias Pf?tzner
> Data Center Ambassador
> Strategy & Technology
> Sun Microsystems GmbH Tel: +49 6103 752-394 (x65394)
> Amp?restra?e 6 Mobile: +49 172 8428766
> 63225 Langen Fax: +49 6103 752-167
> Germany mailto:Matthias.Pfuetzner at Sun.COM
> ***********************************************************************
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
Matthias Pfützner - Data Center Ambassador - Strategy and Technology
2006-Jan-13 10:48 UTC
[dtrace-discuss] Re: dtrace in my kernel module, what''s the problem?
Roch,
that''s the first answer, that explains the stuff to me, in a way, that
I do
understand (OK, currently I''m fighting a little flu, so am slower in
perceiving and recognizing... ;-))
I would have loved to have a chapter (even it it''s just that 5 to 10
lines
below!) in the docs, explaining just that, and a reference in the index of the
docs under "kernel module". There is no such thing there, and after
having
read for more then 4 hours, and some of the first answers, I assumed, that
that is the case, but had not been sure still...
Thanks!
Matthias
You (Roch Bourbonnais - Performance Engineering) write:>
>
> <Sorry If missed a previous answer here;>
>
> It seems that your just getting fooled by the amazing design
> of dtrace. If you have a kernel driver and you want to
> dtrace into some of it''s functions you need not do anything.
>
> Compile your driver (with whatever compiler suits you).
> Install and load into a dtrace enabled kernel.
>
> All your functions* are now instrumentable with dtrace:
>
> dtrace -n
''fbt::saa713x_print_ioctl:entry{@a[stack(20)]=count()}''
>
> -----------------------------------------
> * some hand crafted assembly will not be.
>
>
> If you want DTRACE to know the types of the arguments to your
> functions then you need to run ctf on your driver but that''s
> not mandatory; You still have access to the arguments but
> you need to cast them to proper types in your d-scripts.
>
> if you want DTRACE probe point somewhere which is not at a
> function boundary then you need to use the DTRACE_PROBEX()
> (and #include <sys/sdt.h>). Then insert in you code:
>
> DTRACE_PROBE(myprobe)
>
> That would show (once the driver is loaded) as
>
> dtrace -n ''sdt:::myprobe{}''
>
> If you use myprobe in multiple functions; it will show up as
> multiple probes to dtrace:
>
> dtrace -n ''sdt::f1:myprobe{}'' -n
''sdt::f2:myprobe{}''
>
> HTH
>
> -r
>
>
> Matthias Pf?tzne r - Data Center Ambassador - Strategy and Technology
writes:
> > Perhaps I need to ask the question differently:
> >
> > What do I need to do to enable a kernel driver to be dtrace-able?
> >
> > Aka: What code do I need to put into the kernel driver source, so
that it
> > becomes accessable via dtrace?
> >
> > I already learned, that my kernel driver will not become a new
provider,
> > that''s OK.
> >
> > I already learned, that i need to "somehow register" my
variables, routines,
> > whatever to be "seen" by the dtrace kernel stuff...
> >
> > So, a "HowTo" for driver developpers might be helpful! (As
I have been
> > searching now for hours, but didn''t find any easy to follow
guidelines
> > yet... ;-( )
> >
> > Matthias
> >
> > I (Matthias Pf?tzner - Data Center Ambassador - Strategy and
Technology) wrote:
> > > It can''t be that chapter...
> > >
> > > Because it starts:
> > >
> > > The Statically Defined Tracing (SDT) provider creates probes at
sites that a software programmer has formally designated. The SDT mechanism
allows programmers to consciously choose locations of interest to users of
DTrace and to convey some semantic knowledge about each location through the
probe name. The Solaris kernel has defined a handful of SDT probes, and will
likely add more over time. DTrace also provides a mechanism for user application
developers to define static probes, described in Chapter 34, Statically Defined
Tracing for User Applications.
> > >
> > > Still curious (and now, for the first time to the dtrace-alias),
> > > Matthias
> > >
> > > I (Matthias Pf?tzner - Data Center Ambassador - Strategy and
Technology) wrote:
> > > > Adam,
> > > >
> > > > the problem is clear to me, but i didn''t find the
kernel chapter... ;-)
> > > >
> > > > Here''s the TOC:
> > > >
> > > > * Index
> > > > * Book Information
> > > > * Preface
> > > > * 1. Introduction
> > > > * 2. Types, Operators, and Expressions
> > > > * 3. Variables
> > > > * 4. D Program Structure
> > > > * 5. Pointers and Arrays
> > > > * 6. Strings
> > > > * 7. Structs and Unions
> > > > * 8. Type and Constant Definitions
> > > > * 9. Aggregations
> > > > * 10. Actions and Subroutines
> > > > * 11. Buffers and Buffering
> > > > * 12. Output Formatting
> > > > * 13. Speculative Tracing
> > > > * 14. dtrace(1M) Utility
> > > > * 15. Scripting
> > > > * 16. Options and Tunables
> > > > * 17. dtrace Provider
> > > > * 18. lockstat Provider
> > > > * 19. profile Provider
> > > > * 20. fbt Provider
> > > > * 21. syscall Provider
> > > > * 22. sdt Provider
> > > > * 23. sysinfo Provider
> > > > * 24. vminfo Provider
> > > > * 25. proc Provider
> > > > * 26. sched Provider
> > > > * 27. io Provider
> > > > * 28. mib Provider
> > > > * 29. fpuinfo Provider
> > > > * 30. pid Provider
> > > > * 31. plockstat Provider
> > > > * 32. fasttrap Provider
> > > > * 33. User Process Tracing
> > > > * 34. Statically Defined Tracing for User Applications
> > > > * 35. Security
> > > > * 36. Anonymous Tracing
> > > > * 37. Postmortem Tracing
> > > > * 38. Performance Considerations
> > > > * 39. Stability
> > > > * 40. Translators
> > > > * 41. Versioning
> > > > * Glossary
> > > >
> > > > Which chapter is the kernel tracing developing
"info-container"? The "sdt"
> > > > chapter, aka chapter 22?
> > > >
> > > > Still curious...
> > > >
> > > > Matthias
> > > >
> > > > You (Adam Leventhal) write:
> > > > > Hi Matthias,
> > > > >
> > > > > Please post this question to dtrace-discuss at
opensolaris.org, but the short
> > > > > answer is that USDT is just for _user_ land binaries;
for (kernel) SDT
> > > > > check that chapter in the Solaris Dynamic Tracing
Guide.
> > > > >
> > > > > Adam
> > > > >
> > > > > On Wed, Jan 11, 2006 at 09:46:45PM +0100, Matthias
Pftzner - Data Center Ambassador - Strategy and Technology wrote:
> > > > > > Folks,
> > > > > >
> > > > > > I try to add dtrace points to "my"
kernel module, but do get errors during
> > > > > > the compile.
> > > > > >
> > > > > > /usr/sbin/dtrace -G -32 -s
saa713xdtrace.d obj-i386/saa713x-core.o obj-i386/saa713x-video.o
obj-i386/saa713x-cards.o obj-i386/saa713x-tvaudio.o obj-i386/saa713x-i2c.o
> > > > > > dtrace: failed to link script
saa713xdtrace: an error was encountered while processing obj-i386/saa713x-core.o
> > > > > >
> > > > > > Here''s the code:
> > > > > >
> > > > > > bash-3.00$ cat saa713xdtrace.d
> > > > > > provider saa713xdtrace {
> > > > > > probe routine__enter(string);
> > > > > > probe routine__exit(string);
> > > > > > };
> > > > > > bash-3.00$
> > > > > >
> > > > > > And in the file saa713x-core.c I do have:
> > > > > >
> > > > > > #include <sys/sdt.h>
> > > > > >
> > > > > > void saa713x_print_ioctl(char *name, unsigned int
cmd)
> > > > > > {
> > > > > > const char *cmdnm;
> > > > > > char *dir = "??";
> > > > > >
> > > > > > DTRACE_PROBE1(saa713xdtrace,
routine__enter, "saa713x_print_ioctl");
> > > > > > /*
> > > > > > * IOR/read == IOC_OUT ==
kernel->user
> > > > > > * IOW/write == IOC_IN ==
user->kernel
> > > > > > */
> > > > > > switch (cmd & IOC_INOUT) {
> > > > > >
> > > > > > et.al...
> > > > > >
> > > > > > So, what''s the problem, the error
message isn''t really helpful... ;-(
> > > > > >
> > > > > > All infos I found on this stuff is in:
> > > > > >
> > > > > >
http://docs.sun.com/app/docs/doc/817-6223/6mlkidlms?a=view
> > > > > >
> > > > > > Is there more? I did not find anything under:
> > > > > >
> > > > > >
http://www.sun.com/bigadmin/content/dtrace/
> > > > > >
> > > > > > Clueless,
> > > > > > Matthias
> > > > > > --
> > > > > >
***********************************************************************
> > > > > > Matthias Pf?tzner
> > > > > > Data Center Ambassador
> > > > > > Strategy & Technology
> > > > > > Sun Microsystems GmbH Tel: +49
6103 752-394 (x65394)
> > > > > > Amp?restra?e 6 Mobile: +49
172 8428766
> > > > > > 63225 Langen Fax: +49
6103 752-167
> > > > > > Germany
mailto:Matthias.Pfuetzner at Sun.COM
> > > > > >
***********************************************************************
> > > > >
> > > > > --
> > > > > Adam Leventhal, Solaris Kernel Development
http://blogs.sun.com/ahl
> > > >
> > > > --
> > > >
***********************************************************************
> > > > Matthias Pf?tzner
> > > > Data Center Ambassador
> > > > Strategy & Technology
> > > > Sun Microsystems GmbH Tel: +49 6103 752-394
(x65394)
> > > > Amp?restra?e 6 Mobile: +49 172
8428766
> > > > 63225 Langen Fax: +49 6103 752-167
> > > > Germany
mailto:Matthias.Pfuetzner at Sun.COM
> > > >
***********************************************************************
> > >
> > > --
> > >
***********************************************************************
> > > Matthias Pf?tzner
> > > Data Center Ambassador
> > > Strategy & Technology
> > > Sun Microsystems GmbH Tel: +49 6103 752-394
(x65394)
> > > Amp?restra?e 6 Mobile: +49 172 8428766
> > > 63225 Langen Fax: +49 6103 752-167
> > > Germany mailto:Matthias.Pfuetzner
at Sun.COM
> > >
***********************************************************************
> >
> > --
> >
***********************************************************************
> > Matthias Pf?tzner
> > Data Center Ambassador
> > Strategy & Technology
> > Sun Microsystems GmbH Tel: +49 6103 752-394 (x65394)
> > Amp?restra?e 6 Mobile: +49 172 8428766
> > 63225 Langen Fax: +49 6103 752-167
> > Germany mailto:Matthias.Pfuetzner at
Sun.COM
> >
***********************************************************************
> > _______________________________________________
> > dtrace-discuss mailing list
> > dtrace-discuss at opensolaris.org
>
--
***********************************************************************
Matthias Pf?tzner
Data Center Ambassador
Strategy & Technology
Sun Microsystems GmbH Tel: +49 6103 752-394 (x65394)
Amp?restra?e 6 Mobile: +49 172 8428766
63225 Langen Fax: +49 6103 752-167
Germany mailto:Matthias.Pfuetzner at Sun.COM
***********************************************************************