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
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
