I''m working on adding USDT probes to a library. The library is built in ON and hence includes CTF data. I''ve set up a number of translators for the probes to use to avoid exposing the internals of the library. Unfortunately it appears as though dtrace can''t take advantage of the CTF data in userspace libraries to walk library data structures. The library data-structures are complex and cannot simply be included in the provider support file so I have to resort to teaching the library to setup the arguments for dtrace to consume with an intermediate data structure. This data strucutre can be then included in the provider support file (in /usr/lib/dtrace). I couldn''t find a CR/RFE tracking this. Is there one? Thanks, -M
On Tue, Feb 16, 2010 at 02:12:35PM +0100, Mark Phalan wrote:> I''m working on adding USDT probes to a library. The library is built in > ON and hence includes CTF data. I''ve set up a number of translators for > the probes to use to avoid exposing the internals of the library. > Unfortunately it appears as though dtrace can''t take advantage of the > CTF data in userspace libraries to walk library data structures. The > library data-structures are complex and cannot simply be included in the > provider support file so I have to resort to teaching the library to > setup the arguments for dtrace to consume with an intermediate data > structure. This data strucutre can be then included in the provider > support file (in /usr/lib/dtrace). > > I couldn''t find a CR/RFE tracking this. Is there one?What you''re looking for is called "is-enabled" probes. These are probes that do have disabled probe effects (a branch, basically). You get to gather the data needed for the probes only when the probes are enabled. User-land pointer chasing and structured type handling via simple syntax that relies CTF is not a feature of DTrace right now; you can only do that in kernel-land. Nico --
On 02/16/10 02:31 PM, Nicolas Williams wrote:> On Tue, Feb 16, 2010 at 02:12:35PM +0100, Mark Phalan wrote: >> I''m working on adding USDT probes to a library. The library is built in >> ON and hence includes CTF data. I''ve set up a number of translators for >> the probes to use to avoid exposing the internals of the library. >> Unfortunately it appears as though dtrace can''t take advantage of the >> CTF data in userspace libraries to walk library data structures. The >> library data-structures are complex and cannot simply be included in the >> provider support file so I have to resort to teaching the library to >> setup the arguments for dtrace to consume with an intermediate data >> structure. This data strucutre can be then included in the provider >> support file (in /usr/lib/dtrace). >> >> I couldn''t find a CR/RFE tracking this. Is there one? > > What you''re looking for is called "is-enabled" probes. These are probes > that do have disabled probe effects (a branch, basically). You get to > gather the data needed for the probes only when the probes are enabled.Yup, I''m planning on using the is-enabled probes to reduce the run-time cost of building the arguments when the probes aren''t enabled.> > User-land pointer chasing and structured type handling via simple syntax > that relies CTF is not a feature of DTrace right now; you can only do > that in kernel-land.Thats what I feared :( I couldn''t find the CR tracking that though. Perhaps I should just open one. Thanks, -M
On Tue, Feb 16, 2010 at 02:12:35PM +0100, Mark Phalan wrote:> > I''m working on adding USDT probes to a library. The library is built in > ON and hence includes CTF data. I''ve set up a number of translators for > the probes to use to avoid exposing the internals of the library. > Unfortunately it appears as though dtrace can''t take advantage of the > CTF data in userspace libraries to walk library data structures. The > library data-structures are complex and cannot simply be included in the > provider support file so I have to resort to teaching the library to > setup the arguments for dtrace to consume with an intermediate data > structure. This data strucutre can be then included in the provider > support file (in /usr/lib/dtrace). > > I couldn''t find a CR/RFE tracking this. Is there one?No, there is not. You are welcome to file one, but be aware that this is not a small amount of work: to do this properly requires dynamic translators, an idea that we had somewhat sketched out, but had only begun to implement when we became distracted by more ambitious projects. So your best bet for the immediate future is to do exactly what you (and others) have done: define an intermediate structure in both your header file and the .d file that you can easily translate from (in D) and to (in your library''s C code, in an is-enabled probe). Yes, this is a bit filthy -- but (1) it''s only filthy for provider authors and (2) dynamic translators are a hell of a lot of work. - Bryan -------------------------------------------------------------------------- Bryan Cantrill, Sun Microsystems Fishworks. http://blogs.sun.com/bmc
On 02/16/10 04:49 PM, Bryan Cantrill wrote:> On Tue, Feb 16, 2010 at 02:12:35PM +0100, Mark Phalan wrote: >> >> I''m working on adding USDT probes to a library. The library is built in >> ON and hence includes CTF data. I''ve set up a number of translators for >> the probes to use to avoid exposing the internals of the library. >> Unfortunately it appears as though dtrace can''t take advantage of the >> CTF data in userspace libraries to walk library data structures. The >> library data-structures are complex and cannot simply be included in the >> provider support file so I have to resort to teaching the library to >> setup the arguments for dtrace to consume with an intermediate data >> structure. This data strucutre can be then included in the provider >> support file (in /usr/lib/dtrace). >> >> I couldn''t find a CR/RFE tracking this. Is there one? > > No, there is not. You are welcome to file one, but be aware that this is > not a small amount of work: to do this properly requires dynamic > translators, an idea that we had somewhat sketched out, but had only > begun to implement when we became distracted by more ambitious projects. > So your best bet for the immediate future is to do exactly what you > (and others) have done: define an intermediate structure in both your > header file and the .d file that you can easily translate from (in D) > and to (in your library''s C code, in an is-enabled probe). Yes, this > is a bit filthy -- but (1) it''s only filthy for provider authors and > (2) dynamic translators are a hell of a lot of work.Ok, I''ll file an RFE. It would be a very cool feature to have. In the meantime I''ll continue with what I''m currently using. Thanks, -M
On 02/16/10 05:28 PM, Mark Phalan wrote:> On 02/16/10 04:49 PM, Bryan Cantrill wrote: >> On Tue, Feb 16, 2010 at 02:12:35PM +0100, Mark Phalan wrote: >>> >>> I''m working on adding USDT probes to a library. The library is built in >>> ON and hence includes CTF data. I''ve set up a number of translators for >>> the probes to use to avoid exposing the internals of the library. >>> Unfortunately it appears as though dtrace can''t take advantage of the >>> CTF data in userspace libraries to walk library data structures. The >>> library data-structures are complex and cannot simply be included in the >>> provider support file so I have to resort to teaching the library to >>> setup the arguments for dtrace to consume with an intermediate data >>> structure. This data strucutre can be then included in the provider >>> support file (in /usr/lib/dtrace). >>> >>> I couldn''t find a CR/RFE tracking this. Is there one? >> >> No, there is not. You are welcome to file one, but be aware that this is >> not a small amount of work: to do this properly requires dynamic >> translators, an idea that we had somewhat sketched out, but had only >> begun to implement when we became distracted by more ambitious projects. >> So your best bet for the immediate future is to do exactly what you >> (and others) have done: define an intermediate structure in both your >> header file and the .d file that you can easily translate from (in D) >> and to (in your library''s C code, in an is-enabled probe). Yes, this >> is a bit filthy -- but (1) it''s only filthy for provider authors and >> (2) dynamic translators are a hell of a lot of work. > > Ok, I''ll file an RFE. It would be a very cool feature to have. In the > meantime I''ll continue with what I''m currently using.I just opened 6926913 to track this. -M