From owner-freebsd-arch@FreeBSD.ORG Thu Dec 27 04:00:36 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0360A1E5; Thu, 27 Dec 2012 04:00:36 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id D1DE18FC0A; Thu, 27 Dec 2012 04:00:35 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 00BD41A3C33; Wed, 26 Dec 2012 20:00:34 -0800 (PST) Message-ID: <50DBC7E2.1070505@mu.org> Date: Wed, 26 Dec 2012 20:00:34 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Alfred Perlstein Subject: UPDATE Re: making use of userland dtrace on FreeBSD References: <50D49DFF.3060803@ixsystems.com> In-Reply-To: <50D49DFF.3060803@ixsystems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "arch@freebsd.org" , Adrian Chadd , Rui Paulo X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2012 04:00:36 -0000 Putting the following into /etc/src.conf builds a world that is userland dtrace'able: > /usr/home/alfred # cat /etc/src.conf > WITH_CTF=1 > CFLAGS+=-fno-omit-frame-pointer > STRIP= (yes, STRIP is intentionally left blank) The following the wiki, just doing this: > # kldload dtraceall Then you can test it by doing this: > # dtruss -s ls |& head -20 If you get stack traces along with syscalls, you're doing pretty well. Can any of our build gurus look at this? What would be the drawbacks? I don't want to hurt freebsd for heavy performance, but I think this functionality should work out of the box for most people. It allows an expert to diagnose some pretty gnarly bugs. My preliminary thoughts are: hack gcc to turn off -fomit-frame-pointer unless -O3 or greater is specified. turn on WITH_CTF in the Mk files or top level Makefiles. turn off stripping by default. What other options are there? Is there a better way that is expedient? I really do not think we should wait for codes to optimize this unless the code is hiding somewhere on a branch and ready to commit unless there is a strong reason. Can someone list some strong reasons not to? Or give encouragement to go this way? -Alfred On 12/21/12 9:35 AM, Alfred Perlstein wrote: > Hey folks, > > We have had userland dtrace for a while now. However it's not really > hooked up into the build, nor as far as I can tell are ports nor > shared libs. > > Dtrace can be immensely useful for tracking down hard to find bugs, > memory leaks, performance problems and a lot more. > > What are the thoughts on making this available by default on FreeBSD > going forward? > > What would need to happen? > > Supposedly we can do this by just adding > "CFLAGS=-fno-omit-frame-pointer" and not completely stripping > installed tools/libraries. > > Would it make sense to set this as default for the whole system? Just > libs+ports? Or do people think that the performance gain of > omit-frame-pointer (which I am unsure of) is worth the loss of > debug-ability (like a certain arctic bird based OS)? > > I have also factored in the size of binaries into this, and I really > am not sure why it would be a problem other than if we didn't offer an > "easy button" to make things "small". > > Let's figure this out, because it seems to me that we should be > offering this to our users if possible. > > -Alfred > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >