Date: Wed, 26 Dec 2012 20:00:34 -0800 From: Alfred Perlstein <bright@mu.org> To: Alfred Perlstein <alfred@ixsystems.com> Cc: "arch@freebsd.org" <arch@freebsd.org>, Adrian Chadd <adrian@FreeBSD.org>, Rui Paulo <rpaulo@freebsd.org> Subject: UPDATE Re: making use of userland dtrace on FreeBSD Message-ID: <50DBC7E2.1070505@mu.org> In-Reply-To: <50D49DFF.3060803@ixsystems.com> References: <50D49DFF.3060803@ixsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50DBC7E2.1070505>