On Tue, 12 Oct 2010, David O'Brien wrote:
On Wed, Oct 13, 2010 at 02:18:33PM +1100, Bruce Evans wrote:
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'
[..]
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,
This is actually what my motivation is -- trying to set breakpoints and
finding GDB was unable to.
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.
I agree, and would not add STATIC's to a program's code that didn't
already have them. But in this case we inherited it from 4.4BSD.
I'm just making it actually do something other than being a gratuitous
spelling change.
I believe I've made things more consistent with r213760.
Add __noinline or whatever attributes to STATIC (but keep static in
it) for the DEBUG >= 3 case if you are going that far. __noinline
should be a syntax error for variables, so this should also find any
STATICs still on variables. The spelling fix of changing STATIC to
what it actually means
(ASSORTED_HACKS_FOR_DEBUGGING_BUT_NOW_ONLY_FOR_FUNCTIONS) goes too far
for me.
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"
