From owner-svn-src-all@freebsd.org Tue Dec 12 17:32:37 2017 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 40B3BEA00E6; Tue, 12 Dec 2017 17:32:37 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1A96E677A6; Tue, 12 Dec 2017 17:32:36 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id vBCHW5bu087313; Tue, 12 Dec 2017 09:32:05 -0800 (PST) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id vBCHW5UR087312; Tue, 12 Dec 2017 09:32:05 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201712121732.vBCHW5UR087312@pdx.rh.CN85.dnsmgr.net> Subject: Re: svn commit: r326758 - in head/sys/i386: conf include In-Reply-To: <9484a39c-21f1-9174-11ce-54088c3f6099@FreeBSD.org> To: Andriy Gapon Date: Tue, 12 Dec 2017 09:32:05 -0800 (PST) CC: rgrimes@freebsd.org, Eugene Grosbein , Don Lewis , Alexey Dokuchaev , Konstantin Belousov , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Conrad Meyer Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Tue, 12 Dec 2017 23:16:21 +0000 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 17:32:37 -0000 [ Charset UTF-8 unsupported, converting... ] > On 12/12/2017 19:01, Rodney W. Grimes wrote: > > We should probably start looking for those, something someone who is > > offerring help but doesnt know what they might be good at, but can > > read C code. They could be utililized t simply scan through the > > code looking for this type of thing and bring it to the attention > > of a area of expertise commiter. > > By the way, there are tools that can analyze binary code (e.g. a kernel binary > or a module) and determine stack requirements of each function. I think that > debug symbols might be required too. That would be an even better first start, even if it just could tell us what the local var stack space request of each function was that might point out some easly low hanging fruit. Can it also tell us how big the call frame is? > > I am not sure if there are tools that can analyze stack requirements for > possible call chains rather than individual functions. Call graphs can be used to find deep chains. Combine the above with a call graph and we should be able to come up with some data. This also sounds like a good caniate for GSOC, creation of a call graph with static analysis of local variable size + call frame size requirements as a O(1) stack space estimator. -- Rod Grimes rgrimes@freebsd.org