svn commit: r213744 - head/bin/sh

[Bruce Evans]

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