Hi people, When working with some usdt C++ probes we have come across a few issues. Controlling USDT Function name: Putting in usdt probes into C++ code gives you the mangled enclosing function name for the probes Function name. Working around this can be a pain. You need to wrap your usdt probes in extern C functions and call these. Could we have an option to control the Function name for usdt probes, not just the Name in the probe definition file? Accessing ustack entries as strings to aggregate on: Also whilst controlling the Function name we''d still like to be able to access the name of the C++ calling function of our wrapped probe. Is there any way for us to do this? I can use ustack(2) to print out 2 levels of the stack, but what I''d like to be able to do is aggregate on the 2nd level entry up in the stack. Doesn''t appear to be a way to get a string back out of the ustack for an arbitrary call level that I could then put into an aggregation. Tried using the ufunc(uregs[R_PC]) but that''s just giving me the same as probefunc and in a form I can''t seem to print out in a composite aggregate. stack: layout-start trace-layout-entry() [extern C wrapper func] <C++ function from which trace-layout-entry() is being called and whose name we''d like to have access to> Firing Exit probes reliably in C++: In the C++ code blocks we put our probes, the code had multiple exit points and it was error prone to put in matching exit probes for a given entry one. The way we got around it was to create a struct containing our wrapped entry and exit probes in the structs constructor and destructor. We then declare this trace struct anywhere we want to trace, without having to worry about the exit points from this function block. When the struct goes out of scope the exit probe fires in its destructor. Are there any other less complicated ways to achieve this in dtrace? JR
On Fri, Mar 09, 2007 at 09:40:42AM +0000, John Rice wrote:> Controlling USDT Function name: > Putting in usdt probes into C++ code gives you the mangled enclosing > function name for the probes Function name. Working around this can be a > pain. You need to wrap your usdt probes in extern C functions and call > these. Could we have an option to control the Function name for usdt > probes, not just the Name in the probe definition file?We''ve considered this in the past, but prefer the current behavior since we think it''s useful to be able to trace all probes in a given function (e.g. ::func:). It may be that that mode of operation is more relevant in the kernel (since fbt probes, unlike pid probes, are generated without needing to specify them explicitly). Please file an RFE and suggest some syntax for specifying the function name to be published. We''ll consider it and either implement the fix or provide some definitive justification.> Accessing ustack entries as strings to aggregate on: > Also while controlling the Function name we''d still like to be able to > access the name of the C++ calling function of our wrapped probe. Is > there any way for us to do this? I can use ustack(2) to print out 2 > levels of the stack, but what I''d like to be able to do is aggregate on > the 2nd level entry up in the stack. Doesn''t appear to be a way to get a > string back out of the ustack for an arbitrary call level that I could > then put into an aggregation. Tried using the ufunc(uregs[R_PC]) but > that''s just giving me the same as probefunc and in a form I can''t seem > to print out in a composite aggregate.Could you use ufunc(ucaller)?> Firing Exit probes reliably in C++: > In the C++ code blocks we put our probes, the code had multiple exit > points and it was error prone to put in matching exit probes for a given > entry one. The way we got around it was to create a struct containing > our wrapped entry and exit probes in the structs constructor and > destructor. We then declare this trace struct anywhere we want to trace, > without having to worry about the exit points from this function block. > When the struct goes out of scope the exit probe fires in its > destructor. Are there any other less complicated ways to achieve this in > dtrace?It sounds like you should be using the pid provider''s entry and return probes in that case. Am I missing something? Adam -- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl
Adam, Thanks Adman, a few comments: I filed an RFE on Opensolaris; "USDT Probes having control over Function as well as Provider and Name" Never thought of using the ufunc(ucaller). Sounds like a plan, presumably I can walk up the stack by just nesting the calls so to get the 2nd level in the call stack i''d just call ufunc(ufunc(ucaller)). Will try this out tomorrow and see how it goes. Use pid provider entry and return probes: nope. The issue is that we are dealing with very long functions that have many different scoping blocks in the function itself. So you want your entry probe to fire on entry into a defined scoping block and fire on exit from this code block, you are still in the function at this point and no where near the final function exit point, so pid entry/exit probes are no use. We really want a special object probe that on creation fires it''s object create/entry probe and when it goes out of scope fires it''s destruct/exit probe. I know I don''t want much, but I had to ask ;) JR Adam Leventhal wrote:> On Fri, Mar 09, 2007 at 09:40:42AM +0000, John Rice wrote: > >> Controlling USDT Function name: >> Putting in usdt probes into C++ code gives you the mangled enclosing >> function name for the probes Function name. Working around this can be a >> pain. You need to wrap your usdt probes in extern C functions and call >> these. Could we have an option to control the Function name for usdt >> probes, not just the Name in the probe definition file? >> > > We''ve considered this in the past, but prefer the current behavior since > we think it''s useful to be able to trace all probes in a given function > (e.g. ::func:). It may be that that mode of operation is more relevant in > the kernel (since fbt probes, unlike pid probes, are generated without > needing to specify them explicitly). Please file an RFE and suggest some > syntax for specifying the function name to be published. We''ll consider it > and either implement the fix or provide some definitive justification. > > >> Accessing ustack entries as strings to aggregate on: >> Also while controlling the Function name we''d still like to be able to >> access the name of the C++ calling function of our wrapped probe. Is >> there any way for us to do this? I can use ustack(2) to print out 2 >> levels of the stack, but what I''d like to be able to do is aggregate on >> the 2nd level entry up in the stack. Doesn''t appear to be a way to get a >> string back out of the ustack for an arbitrary call level that I could >> then put into an aggregation. Tried using the ufunc(uregs[R_PC]) but >> that''s just giving me the same as probefunc and in a form I can''t seem >> to print out in a composite aggregate. >> > > Could you use ufunc(ucaller)? > > >> Firing Exit probes reliably in C++: >> In the C++ code blocks we put our probes, the code had multiple exit >> points and it was error prone to put in matching exit probes for a given >> entry one. The way we got around it was to create a struct containing >> our wrapped entry and exit probes in the structs constructor and >> destructor. We then declare this trace struct anywhere we want to trace, >> without having to worry about the exit points from this function block. >> When the struct goes out of scope the exit probe fires in its >> destructor. Are there any other less complicated ways to achieve this in >> dtrace? >> > > It sounds like you should be using the pid provider''s entry and return probes > in that case. Am I missing something? > > Adam > >
Opps apologies for the typo Adam, on a Sunray and the keyboard latency is playing games :( JR John Rice wrote:> Adam, > > Thanks Adman, a few comments: > > I filed an RFE on Opensolaris; "USDT Probes having control over > Function as well as Provider and Name" > > Never thought of using the ufunc(ucaller). Sounds like a plan, > presumably I can walk up the stack by just nesting the calls so to get > the 2nd level in the call stack i''d just call ufunc(ufunc(ucaller)). > Will try this out tomorrow and see how it goes. > > Use pid provider entry and return probes: nope. The issue is that we > are dealing with very long functions that have many different scoping > blocks in the function itself. So you want your entry probe to fire on > entry into a defined scoping block and fire on exit from this code > block, you are still in the function at this point and no where near > the final function exit point, so pid entry/exit probes are no use. We > really want a special object probe that on creation fires it''s object > create/entry probe and when it goes out of scope fires it''s > destruct/exit probe. I know I don''t want much, but I had to ask ;) > > JR > > Adam Leventhal wrote: >> On Fri, Mar 09, 2007 at 09:40:42AM +0000, John Rice wrote: >> >>> Controlling USDT Function name: >>> Putting in usdt probes into C++ code gives you the mangled enclosing >>> function name for the probes Function name. Working around this can >>> be a pain. You need to wrap your usdt probes in extern C functions >>> and call these. Could we have an option to control the Function name >>> for usdt probes, not just the Name in the probe definition file? >>> >> >> We''ve considered this in the past, but prefer the current behavior since >> we think it''s useful to be able to trace all probes in a given function >> (e.g. ::func:). It may be that that mode of operation is more >> relevant in >> the kernel (since fbt probes, unlike pid probes, are generated without >> needing to specify them explicitly). Please file an RFE and suggest some >> syntax for specifying the function name to be published. We''ll >> consider it >> and either implement the fix or provide some definitive justification. >> >> >>> Accessing ustack entries as strings to aggregate on: >>> Also while controlling the Function name we''d still like to be able >>> to access the name of the C++ calling function of our wrapped probe. >>> Is there any way for us to do this? I can use ustack(2) to print out >>> 2 levels of the stack, but what I''d like to be able to do is >>> aggregate on the 2nd level entry up in the stack. Doesn''t appear to >>> be a way to get a string back out of the ustack for an arbitrary >>> call level that I could then put into an aggregation. Tried using >>> the ufunc(uregs[R_PC]) but that''s just giving me the same as >>> probefunc and in a form I can''t seem to print out in a composite >>> aggregate. >>> >> >> Could you use ufunc(ucaller)? >> >> >>> Firing Exit probes reliably in C++: >>> In the C++ code blocks we put our probes, the code had multiple exit >>> points and it was error prone to put in matching exit probes for a >>> given entry one. The way we got around it was to create a struct >>> containing our wrapped entry and exit probes in the structs >>> constructor and destructor. We then declare this trace struct >>> anywhere we want to trace, without having to worry about the exit >>> points from this function block. When the struct goes out of scope >>> the exit probe fires in its destructor. Are there any other less >>> complicated ways to achieve this in dtrace? >>> >> >> It sounds like you should be using the pid provider''s entry and >> return probes >> in that case. Am I missing something? >> >> Adam >> >> > > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org
On Tue, Mar 13, 2007 at 11:59:36PM +0000, John Rice wrote:> Never thought of using the ufunc(ucaller). Sounds like a plan, > presumably I can walk up the stack by just nesting the calls so to get > the 2nd level in the call stack i''d just call ufunc(ufunc(ucaller)). > Will try this out tomorrow and see how it goes.Actually you can''t. The ufunc() action will cause DTrace to format an address as a symbol in the process that was running at the time it was traced. The ucaller variable is what gets you the caller. There''s no way to programatically examine the user or kernel stacks -- this has been on many wishlists for a long time. Adam -- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl