similar to: SDT/USDT policies?

X.Org has adopted GNU autoconf as its build configuration mechanism, so when I integrated the dtrace probes, I checked to see if they should be built using this test, checking for the existence of a program named "dtrace" in the path: dnl Check for dtrace program (needed to build Xserver dtrace probes) AC_ARG_WITH(dtrace, AS_HELP_STRING([--with-dtrace=PATH], [Enable dtrace

Hi All, I''ve got a problem when I have USDT probes in a static library and in the application code outside of the library. I build the static library containing some USDT probes, glomming everything together (ld -r) before creating the .a file to preserve the probe symbols. This all works fine. I build an application which also has some USDT probes. When I build the application which

How do I query an application to see if it supports any USDT probe points?

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

Hi, I''m posting a question hoping someone will know the answer off hand thereby reducing my search time. :-) With USDT probes, the tracepoint is only installed by libdtrace itself, never by the drti ioctl. So whenever I run a program with an USDT probe, no tracepoint is installed. Only after I run the dtrace command the tracepoint is actually installed on the victim process. My question

Hi, As I''ve discussed before whenever we add USDT probes to a C++ function and call dtrace -l we get the mangled C++ name for the dtrace function, being listed :( Now the point of USDT probes is to abstract a higher level semantic construct for users to make use of. Surely it is not meant to be listing Unstable Interfaces (implementation details), such as the containing C++

Has anyone seen the following error before? "error on enabled probe ID 2 (ID 473: sdt:unix:av_dispatch_autovect:interrupt-complete): invalid address (0x198) in action #3 at DIF offset 20" I''m trying to capture interrupt times as inlined in the below script. The script gives me some output after the errors, and I''m trying to understand if the errors are affecting

Hi all, So I just took Sun''s dtrace class this week and one thing that piqued my interest was the instrumenting of a process''s instructions and how to find the original instructions. (I''m looking around at resources for learning SPARC assembly to help me when using mdb for analysis, though I vaguely remember pieces from a grad school compiler theory class about 10 years

Hi, I want to use USDT in my java applications. Please tell me how to achieve this. I am comfortable with SDT in C application. I am using Solaris Sparc10 with Generic_120011-14 version. Do I need to update my machine for this? Thanks, Ajit -- This message posted from opensolaris.org

while trying to use the USDT made available to us in Postgresql database I have problems enabling them. On my database server I ran 1024+ PG processes (1024 clients). The server is a 8 core T2000 @1000MHz. 32GB. 7 storage arrays. Solaris 10 Update 4. Home compiled PG 8.3 beta 1 (optimized binary for T1 chip) with DTrace probes enabled. When running without enabling the probes I have approx 25%

Is there any way to get printf type functionality inside the kernel from dtrace probes. Basically I want to dump progress through flow in my device driver. Something like: DTRACE_PRINTF("Inside chip reset, mailboxes %x %x %x %x %x %x %x %x", mb1, mb2, .....); ... ... DTRACE_PRINTF("reset failed: reason %s", failure_reasons[err]); I may have several such probes and they may

[Perhaps someone could rename this list to dtrace-matt-problems-discuss?] If I run this script against my binary (which contains a USDT probe called ''concurrentq-latency''): ::: / probename == "concurrentq-latency" / { printf("[%s]:[%s]:[%s]\n", probeprov, probefunc, probename); } I get this output: dtrace: script ''testq.d'' matched 46056

I have inserted some probes in my application, and it works great in the "debug build" I have been using. So I wanted to look at the "overhead" introduced by inactive dtrace probes in my application. I am using the Sun Studio 11 compiler, so I added the following options: -xO5 -g0 -xbuiltin But this breaks the linking of my application. Undefined first

Suppose I have a USDT probe in Firefox and that I''m trying to catch the startup with a probe like this: proc:::exec-success /execname == "firefox-bin"/ { start = timestamp; } and stop tracing when Firefox hits this USDT probe: mozilla:::main-entry { exit(0); } How do I put the running firefox-bin into "trace mode" so that my USDT probe fires? Thanks, Joel

I have a number of systems running solaris10 and i see the package and binary for dtrace installed however whenever we try to run anything we get this error dtrace: failed to initialize dtrace: DTrace device not available on system the only system in which i dont have this error is the development server that has the full solaris 10 install while others are minimized, do i need additional

Hi, I am adding DTrace probes within NFS v3 client. In my current implementation, I use some tsd_*() functions and kmem_zalloc() function. These functions might be heavy and affect the performance. I want to call this function only when DTrace is running or the DTrace probes are enable. So is there a way to check DTrace is running or DTrace probe is enabled? Regards, Danhua

Hi, I have mentioned before that we have added some sdt dtrace probes in SAX, our APL interpreter. Encouraged by Angelo and Jignesh, I have created a small document (5 pages) describing our experience with it, together with some problems we have encountered and some scripts we use for pretty-printing dtrace outputs. The said document can be found at

Hi, Is there a specific reason the DTRACEHIOC_REMOVE ioctl is deprecated? I found I needed to use it in my Perl USDT provider code[*], which creates providers dynamically at runtime. I wonder if I''m missing a better way of doing the same thing. The situation I''m handling with the remove operation is killing and recreating a perl interpreter in the same process, which

I added a couple of static probes to Firefox to measure actual work done. I could have used a pid$target probe with a function name but work is done within an if statement, which is where I placed the static probes. I''m wondering about my use, though. Is the following significantly more efficient than pid$target::FunName:entry and return? I heard somewhere that $target does not

Hi list, I''m currently trying to build a sdt provider into an application. Before we moved our code into the code itself, parts of the provider were provided by an extension loaded by the program. As a result the function-entry probe already exists. Now if I compile my program with my probes which reimplement function-entry (so provider name and probe name match), I get the following