From owner-freebsd-dtrace@FreeBSD.ORG Sat Jan 11 23:39:01 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 359DA2B9 for ; Sat, 11 Jan 2014 23:39:01 +0000 (UTC) Received: from nm21.bullet.mail.bf1.yahoo.com (nm21.bullet.mail.bf1.yahoo.com [98.139.212.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D366F1FD9 for ; Sat, 11 Jan 2014 23:39:00 +0000 (UTC) Received: from [98.139.212.150] by nm21.bullet.mail.bf1.yahoo.com with NNFMP; 11 Jan 2014 23:38:59 -0000 Received: from [68.142.230.76] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 11 Jan 2014 23:38:59 -0000 Received: from [127.0.0.1] by smtp233.mail.bf1.yahoo.com with NNFMP; 11 Jan 2014 23:38:59 -0000 X-Yahoo-Newman-Id: 332131.42448.bm@smtp233.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: QW6ucTwVM1lvz1P8ddAUc80uxP2r0d8rCJTvLMBaCjDxSrY mx.qMpaJE8UcT1Cz2PbteqQhk7_jRyGUm_53y.tUoibniImwQtRRwvCAG5fm Vh7.uAeCGSadot5x.RRPaRDfevw4QdISv3eVFDG8n4xm1TXHBVmupxlacbf_ 2Su4pvdwB0cdPU9APYn1AMubGqoQ7rflXyIsIJk4b1_O9vN6DEu_1qydvDOU acp7vQA5zGVUR0NBJKqdCLiibw1spc6jhvHRq7zxVcQ2mZdFcdzyqCIoWdMJ Djh4iR5fLVTwoJQ2FCsdzZk16xlziezmESmVhXs8.itgsNAG7.wBaXBO4qm2 z_UvmkAbGv.I9YgdbAPNnirSupVZQJ500po8y0M4QNxA9S6JFbn7Cpg2rXZZ 5i8Fy38AFFMbrMU_KPYGmMYRFCW32JGQ_pbjHrzmUiX.evRm5cwG7zRBnT6W tugvbrsQf8gSPTGbk0cZW_B4dhS_JIGEjhPwTufdVn8PmjSpfRsxBTam.RZ_ Nu2F7Igo..5QyNmecV089O89lju7xQa9PCS8yHcwKRuVAjHs2Llfz6QFBpD9 Y7T9ayad1u0Huu7du54CDyPtW1C2sS1PFn.KcNDcrZnZhwoHOHobaPliA.uT JpKs4xeqsXKJmnNL.jX6bsLZY85FxJtqqUk2JZccxj8yzcg-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf X-Rocket-Received: from [192.168.0.102] (pfg@190.157.126.109 with plain [63.250.193.228]) by smtp233.mail.bf1.yahoo.com with SMTP; 11 Jan 2014 23:38:59 +0000 UTC Message-ID: <52D1D60F.5000500@FreeBSD.org> Date: Sat, 11 Jan 2014 18:38:55 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Robert Mustacchi , freebsd-dtrace@freebsd.org Subject: Re: CTF vs dwarf4 References: <52CEEE3B.7010400@FreeBSD.org> <52CEFA91.3090301@joyent.com> <52CF0A42.6090601@FreeBSD.org> <52D1B0C2.7000100@joyent.com> In-Reply-To: <52D1B0C2.7000100@joyent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 23:39:01 -0000 Hi Robert; On 11.01.2014 15:59, Robert Mustacchi wrote: > Sorry for the delay in getting back to you. Don't worry, I am doing other stuff myself. > 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. I read somewhere that Oracle had been sponsoring someone to work on the Solaris clang support, so I couldn't call off the chances. I looked at it briefly (I am not really working on this atm), and one small inconvenience is that the llvm stuff is C++. > 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. I think it's mostly unavoidable. You just can't keep using an old unsupported compiler for too long. > 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. Luckily both the SGI and FreeBSD/elftoolchain libdwarf use the same API. I haven't had much luck finding out about the dwarf4 support in it but I think it looks like the best option. Pedro.