On 7 Sep 2010, at 17:38, Adam Leventhal wrote:
I'm having a problem with USDT probes on FreeBSD. What probes should the
child process have when the parent is the one who installs USDT probes?
I see a problem with postgresql where drti.o installs the USDT probes but
then postgresql forks
I'm having a problem with USDT probes on FreeBSD. What probes should the
child process have when the parent is the one who installs USDT probes?
I see a problem with postgresql where drti.o installs the USDT probes but
then postgresql forks and the new child(s) don't install any new probes.
Hi,
I'm having a problem with USDT probes on FreeBSD. What probes should the child
process have when the parent is the one who installs USDT probes?
I see a problem with postgresql where drti.o installs the USDT probes but then
postgresql forks and the new child(s) don't install any new probes.
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
Hey Rui,
There are two relocations that take place. The provider.o file (generated by
dtrace -G) contains relocations that are resolved with the final link pass
occurs. We record the function offset (libdtrace) and then the linker adds in
the base address of the function. The next relocation
On 10 Aug 2010, at 19:29, Adam Leventhal wrote:
Hey Rui,
There are two relocations that take place. The provider.o file (generated by
dtrace -G) contains relocations that are resolved with the final link pass
occurs. We record the function offset (libdtrace) and then the linker adds in
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
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
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
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
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
SUN Microsystems
- Original Message -
From: Adam Leventhal a...@eng.sun.com
Date: Wednesday, September 17, 2008 7:17 pm
Subject: Re: [dtrace-discuss] USDT probes in both static libraryand
application
To: Christopher Dumoulin dumou
I'd follow up to see if there is any progress on this issue:
a static library and an application cannot currently provide USDT
probes simultaneously?
There is no progress on this issue. I suggest you find the relevant
bug and add a call record.
Adam
--
Adam Leventhal, Fishworks
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
What about the expense of matching on the function name?
You are saying that the kernel trap overwhelms that, right?
On Sep 9, 2009, at 10:20 PM, Chad Mynhier wrote:
No, it's not significantly more efficient. Both function entry/return
probes and USDT probes involve replacing an instruction
To be more explicit, my concerns are about the effect of function
name entry/return probes vs static probes on elapsed time,
as measured by timestamp.
I'm viewing all my timings as a percentage of total elapsed time
and I'm wondering if there's less overhead in using static probes
in this
On Sep 9, 2009, at 2:10 PM, Joel Reymont wrote:
I'm wondering about my use, though. Is the following significantly
more efficient than pid$target::FunName:entry and return?
The cost of the actual probe firing is the same.
The *eval-time* cost of finding out which probes exist and
Do you know if there has been any progress on this? I don't see a
bug to reference to track it down ..
Hey Michael,
I don't see a bug on this either. Would you mind filing it so that it
doesn't fall off my radar again? Thanks.
Adam
--
Adam Leventhal, Fishworks
Hey Chris,
I'm not aware of any work around, but this is a known issue and something
that we'd like to address. Sorry I can't be more helpful.
Adam
On Tue, Sep 16, 2008 at 03:04:42PM -0400, Christopher Dumoulin wrote:
Hi All,
I've got a problem when I have USDT probes in a static library and
19 matches
Mail list logo
