Re: Getting started with DTrace in FreeBSD-current (a.k.a. 8)

From: John Birrell <jb_at_what-creek.com>
Date: Sun, 22 Jun 2008 08:23:48 +0000
On Sun, Jun 22, 2008 at 04:50:20PM +1000, Peter Jeremy wrote:
> On 2008-Jun-21 21:21:21 +0000, John Birrell <jb_at_what-creek.com> wrote:
> >The fact that uid_t is not being recognised is just a consequence of
> >dtrace being used without CTF data in the kernel. If you haven't got
> >CTF data in your kernel, then dtrace is of no use to you.
> 
> How easy would it be to fix this?

The Xorg port shouldn't do things that don't work on FreeBSD. :-)

It wasn't a problem before because the Xorg port didn't find a program
called 'dtrace' in the path, so it just ignored it. Now that there _is_
a program called 'dtrace' in the path, the Xorg port mistakenly
assumes that it can (a) use it; and (b) that it will work the same
way that it does on Solaris. It is wrong on at least the first count
and quite possibly the second.

> 
> IMHO, we should be able to build DTrace-ready applications on a system
> without DTrace installed.  The whole point of the package mechanism is
> to be able to build on one system and run on another - consider trying
> to debug problems on a thin client.  Ideally (IMHO), we should be able
> to run a DTrace-enabled application on a non-DTrace kernel (obviously
> without DTrace).

You *can't* build DTrace-ready userland applications with DTrace probes
in them without DTrace because you need to use the 'dtrace' application
to generate the ELF section that is linked into the application. That is
the way that Sun designed it. Of course for them it is simple because
they always have the ctf tools, dtrace(1) and CTF data in their kernel.

I think you have found an enormous clean-room project to work on. :-D

--
John Birrell
Received on Sun Jun 22 2008 - 06:23:49 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:32 UTC