From owner-svn-src-head@FreeBSD.ORG Thu Oct 14 01:30:40 2010 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7E75106564A; Thu, 14 Oct 2010 01:30:40 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail08.syd.optusnet.com.au (mail08.syd.optusnet.com.au [211.29.132.189]) by mx1.freebsd.org (Postfix) with ESMTP id 7B4268FC1B; Thu, 14 Oct 2010 01:30:40 +0000 (UTC) Received: from c122-106-146-165.carlnfd1.nsw.optusnet.com.au (c122-106-146-165.carlnfd1.nsw.optusnet.com.au [122.106.146.165]) by mail08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o9E1Ubgo019757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Oct 2010 12:30:38 +1100 Date: Thu, 14 Oct 2010 12:30:37 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: John Baldwin In-Reply-To: <201010130907.59715.jhb@freebsd.org> Message-ID: <20101014121846.O1092@besplex.bde.org> References: <201010121924.o9CJOgwn059485@svn.freebsd.org> <20101013040543.GB13694@dragon.NUXI.org> <20101013152037.S2102@besplex.bde.org> <201010130907.59715.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, David O'Brien , Bruce Evans Subject: Re: svn commit: r213744 - head/bin/sh X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 01:30:41 -0000 On Wed, 13 Oct 2010, John Baldwin wrote: > On Wednesday, October 13, 2010 12:29:27 am Bruce Evans wrote: >> On Tue, 12 Oct 2010, David O'Brien wrote: >> >>> On Wed, Oct 13, 2010 at 02:18:33PM +1100, Bruce Evans wrote: >>> ... >>>> 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. > > To be honest, I think changing STATIC is excessive churn. I agree, but 'static' was already spelled 'STATIC' in all cases without style bugs (except in the #define of STATIC). Adding __noinline to the #define of STATIC is a small change. > The "right" fix > is to use 'make DEBUG_FLAGS="-g -DDEBUG=2 -fno-inline"'. I often use > 'make DEBUG_FLAGS="-g -fno-inline"' to workaround excessive inlining when > debugging. I think all of the STATIC changes should just be backed out. Adding -fno-inline on the command line is more flexible, but might change the generated code too much. Sometimes you want to keep all the little inline functions inline so as not to see them, or just to give the same code for them. -fno-inline-functions-called-once may be more useful. -fno-inline doesn't affect functions declared as __inline, so in the kernel where __inline is used too much, -fno-inline doesn't have such a large effect. Putting the non-inlining flag in the definition of STATIC gives even finer control. But I would only use it if STATIC is already used. I would try the hack of "#define static /**/" or "#define static __noinline_mumble" before changing the source code. Bruce