Date: Wed, 13 Oct 2010 14:18:33 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: "David E. O'Brien" <obrien@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r213744 - head/bin/sh Message-ID: <20101013133713.L1075@besplex.bde.org> In-Reply-To: <201010121924.o9CJOgwn059485@svn.freebsd.org> References: <201010121924.o9CJOgwn059485@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101013133713.L1075>