svn commit: r213744 - head/bin/sh

Bruce Evans brde at optusnet.com.au
Wed Oct 13 04:29:32 UTC 2010


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


More information about the svn-src-all mailing list