From owner-freebsd-dtrace@FreeBSD.ORG Sat Jan 11 21:07:18 2014 Return-Path: Delivered-To: freebsd-dtrace@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3216798C for ; Sat, 11 Jan 2014 21:07:18 +0000 (UTC) Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 039571504 for ; Sat, 11 Jan 2014 21:07:17 +0000 (UTC) Received: by mail-pd0-f180.google.com with SMTP id q10so5913059pdj.25 for ; Sat, 11 Jan 2014 13:07:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=eTSMugk9OwYGkN1wlqVafAqyg2dofqEDZXtwu2rthVU=; b=J62yw5qUKzjbeRiMF/6Xo5Smpb7NpJnd+Z6TQ04ttyAlbYDqRt51kspZk3QMBZaXLb fwX0PeT1RIcyr5oaK26vG0bitTxjbCnuarjaG6+qo0YTZOPs3d70M8zBnnD1dC7j/+dD E1S00taIe6ZlyeLgj0+XwPuZWfmKN8hEusqow5U8rsL/dtRVKGgUi1w+aRB+PRrJksRJ KnmBSdeDKnxC6LuCVtuCu7vrvWdcr7eGXtIl2Myebp5R3EqD/jUD/4MHRcqGxVFRx5FU lrDdk3bZ4ekeHeZgehGpP6/GUo4+rIiH1ca3/TtD8/yFtyXaJUhJBI7JmIF/EHXaqQqb P3jQ== X-Gm-Message-State: ALoCoQmOeT94hICvM1vit+QvepSXsw0rns7XuwjIvg/9BhztcdPMHgnk8S8EPqJtCuScO0pNhY6V X-Received: by 10.66.197.164 with SMTP id iv4mr20508019pac.18.1389473989534; Sat, 11 Jan 2014 12:59:49 -0800 (PST) Received: from [10.138.0.3] (c-69-181-44-24.hsd1.ca.comcast.net. [69.181.44.24]) by mx.google.com with ESMTPSA id dq3sm26658609pbc.35.2014.01.11.12.59.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 11 Jan 2014 12:59:48 -0800 (PST) Message-ID: <52D1B0C2.7000100@joyent.com> Date: Sat, 11 Jan 2014 12:59:46 -0800 From: Robert Mustacchi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Pedro Giffuni , freebsd-dtrace@freebsd.org Subject: Re: CTF vs dwarf4 References: <52CEEE3B.7010400@FreeBSD.org> <52CEFA91.3090301@joyent.com> <52CF0A42.6090601@FreeBSD.org> In-Reply-To: <52CF0A42.6090601@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A discussion list for developers working on DTrace in FreeBSD." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 21:07:18 -0000 Sorry for the delay in getting back to you. On 01/09/2014 12:44 PM, Pedro Giffuni wrote: >> Currently I've been retooling ctfconvert + ctfmerge to be actually >> implemented in terms of libctf to make it easier for other things to >> actually consume, such as more long term illumos ld(1) and ideally the >> compilers themselves. None of this code is finished or in illumos yet. >> That really means that I have a slightly more useful merge (and as a >> result diff) written, and convert is kind of a work in progress. > As a side note ... completely unrelated to the issue at hand. > > I don't know much about how DTrace uses dwarf, but I had some contact > with the Oracle guys doing the linux port and I think they are doing > something drastically different to illumos (and FreeBSD). They are > avoiding the issue of getting DTrace in the kernel and they are using > dwarf2 instead of the stabs-like format supported by CTF. Their stuff is > in a GIT repository somewhere but I would have to dig deep in my private > email for the finer details. They were likely to have problems with > dwarf4 too. Today DTrace uses this kind of information so that it knows how to refer to types in both userland (on illumos) and the kernel, and how if you do args[x], it knows the type and allows you to dereference it. >> Probably the simplest way forward that we can all leverage is writing a >> new ctfconvert in terms of DWARF4 that can exist side by side the old >> one. eg. if you have an older compiler with dwarf2 (or you're still >> stuck with stabs or some other language has its own exquisite format), >> that'll still work. illumos last updated libdwarf in 2011. If there's a >> newer libdwarf that has better DWARF4 support or we need to come up with >> something else, let's make sure not to duplicate effort. > > I recall Illumos is using SGI's libdwarf which we have avoiding using > mainly because it's copyleft but I recall there were also some > implementation details that made it undesirable. I haven't followed the > SGI libdwarf but when I last tried to update the pre-packaged port I > noticed it was becoming more difficult to port to non-linux (that may > have been solved though). > > Some FreeBSD developers reimplemented libelf and libdwarf specifically > to use it in DTrace: > http://sourceforge.net/p/elftoolchain/wiki/libdwarf/ > > Their implementation is very clean and portable and it's basically what > we have been using but we have to update it and I am not sure about > their dwarf4 support. > > If illumos and freebsd can use the same libdwarf than that would be > good. OTOH, with llvm having support for dwarf4 it would certainly be > tempting to try to integrate what we can with the toolchain. I don't see > illumos advancing much in the llvm direction though, so this option > would be good for FreeBSD but probably not for illumos. I don't see us moving to the llvm/clang world anytime soon unless someone else picks that up and starts teaching it some of the things we've taught gcc. But as we slowly move compilers, we're also probably going to stick to forcing it to emit dwarf2 for the core gate, unless we have a compelling reason to switch to dwarf4. Though despite that, for at least Joyent's equivalent of ports (netbsd pkgsrc), it's probably more worthwhile to get the dwarf4 support. As for libdwarf, the ctf tools are currently our only consumer of libdwarf. There isn't anything that compels us to stick with it, so we could probably move towards the same libdwarf that FreeBSD works on. I'll take a look at that in my current CTF workspace. So if FBSD is willing to continue down the libdwarf angle, I'd be happy to collaborate where I can with that. Robert