Date: Thu, 25 May 2006 19:53:46 +0000 From: John Birrell <jb@what-creek.com> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: current@freebsd.org Subject: Re: DTrace for FreeBSD - Status Update Message-ID: <20060525195346.GA25270@what-creek.com> In-Reply-To: <20060525082633.GA724@turion.vk2pj.dyndns.org> References: <20060525065510.GA20475@what-creek.com> <20060525082633.GA724@turion.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 25, 2006 at 06:26:33PM +1000, Peter Jeremy wrote: > I'd like to help but not sure if I have the time. Do you have more > detail on what is needed? Most of the stuff is listed in my to-do list. On the build side, the CTF tools are threaded and I am building them as bootstrap tools because they are required to add the CTF data to objects and programs during a buildworld. Sun's code requires a couple of extra non-standard functions in libpthread. I've added those, but doing so creates an upgrade issue which could be solved either by building libpthread in the bootstrap phase of buildworld (yuk) or by creating stubs with weak symbols in the CTF library to resolve the missing functions during the upgrade. The CTF tools themselves complain about some things in buildworld which result in things not being added to the CTF data. This is pretty simple to debug, but it is time consuming. > BTW, how much of DTrace is MD and what CPU architectures are supported? Most of DTrace is machine independent. Sun's code supports Sparc, i386 and amd68, so it's 64-bit clean and supports both endians. Internally DTrace uses what is known as DTrace Intermediate Format (DIF) which is an interpreted instruction set based on RISC-like instructions. All that code is machine independent and thus easy to get working on other architectures. The place were DTrace is really, really machine dependent is in the trap handling code. DTrace has what it calls 'safe' loads where it goes to read from a memory address which a flag set to stop a panic if a trap occurs during the message access. Also, the Function Boundary Tracing (fbt) provider hooks itself into the code at runtime by replacing certain instructions with an invalid opcode so that it deliberately causes a trap which it then catches to do it's magic. At least that's how it works on i386/amd64. On Sparc it's done differently -- I haven't looked into that yet because I don't have access to a Sparc machine (and to port code that affects trap handling, I really need the machine next to me so that I can crash it frequently 8->). -- John Birrell
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060525195346.GA25270>