From owner-svn-src-all@FreeBSD.ORG Wed Oct 13 03:18:37 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F5B1106564A; Wed, 13 Oct 2010 03:18:37 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail08.syd.optusnet.com.au (mail08.syd.optusnet.com.au [211.29.132.189]) by mx1.freebsd.org (Postfix) with ESMTP id E23038FC08; Wed, 13 Oct 2010 03:18:36 +0000 (UTC) Received: from c122-106-146-165.carlnfd1.nsw.optusnet.com.au (c122-106-146-165.carlnfd1.nsw.optusnet.com.au [122.106.146.165]) by mail08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o9D3IXCE027923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Oct 2010 14:18:34 +1100 Date: Wed, 13 Oct 2010 14:18:33 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: "David E. O'Brien" In-Reply-To: <201010121924.o9CJOgwn059485@svn.freebsd.org> Message-ID: <20101013133713.L1075@besplex.bde.org> References: <201010121924.o9CJOgwn059485@svn.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r213744 - head/bin/sh X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 03:18:37 -0000 On Tue, 12 Oct 2010, David E. O'Brien wrote: > Log: > If DEBUG is 3 or greater, disable STATICization of functions. > Also correct the documented location of the trace file. Private functions should always be static, which no `#define STATIC static' hack to control this, but there are compiler bugs that result in them being inlined too often. DEBUG=3 also disables staticization of many or all static variables, since STATIC is used for both functions and variables. Variable names might more reasonably be not unique. > Modified: head/bin/sh/Makefile > ============================================================================== > --- head/bin/sh/Makefile Tue Oct 12 19:24:29 2010 (r213743) > +++ head/bin/sh/Makefile Tue Oct 12 19:24:41 2010 (r213744) > @@ -21,7 +21,7 @@ LDADD= -ll -ledit -ltermcap > LFLAGS= -8 # 8-bit lex scanner for arithmetic > CFLAGS+=-DSHELL -I. -I${.CURDIR} > # for debug: > -# CFLAGS+= -g -DDEBUG=2 > +# CFLAGS+= -g -DDEBUG=3 > WARNS?= 2 > WFORMAT=0 > -O2 and perhaps even -O now does excessive inlining (due to it implying -funit-at-a-time -finline-functions-call-once). This gets in the way of debugging even more than the broken default of -O2 , even with -g. (OTOH, -g is supposed to not change the object code, so it shouldn't undo parts of -O2.) In theory, the debugging info should make it possible for debuggers to restore the semantics of not-explictly-inline functions by virtualizing them, but gdb's debugging info and/or gdb are too primitive to do this (gdb doesn't allow putting a breakpoint at a deleted static function, and at least in FreeBSD, at least on amd64 and i386, gdb makes a mess of even stepping over an explicit inline function -- it doesn't even display the source code for lines that call an inline function (this is even worse than for macros), and thus it doesn't even give a chance of stepping over an inline function using 'n' -- stepping stops in the inline function and displays its lines (except for nested inlines -- then it only displays the leaf lines) (this is better than for macros where you can't see the internals). These bugs are larger for the kernel with primitive instruction-level debuggers like ddb and primitive backtracers that don't understand the debugging info. It can be very hard to see where you are in a large function comprised of other large functions that were inlined just because they are only called once, especially after -O2 reorders everything. These bugs are larger when the inlines are not explicit. You may have made a function separate just for easier debugging, or to get separate profiling info for it... Of course, debugging and profiling are magic, but I don't want to have to adorn all functions with STATICs and __attributes() (and pragmas for othercc...) to recover historical/normal or variant debugging or profiling of them. This already stopped me from adding attributes to inline functions in kernel headers. Not inlining them would be usefulfor re-profiling them to see if they really should be inline, but the control structure for this would be ugly. Bruce