From owner-freebsd-current Thu Apr 13 16:37:36 2000 Delivered-To: freebsd-current@freebsd.org Received: from alcanet.com.au (mail.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 197D937B718 for ; Thu, 13 Apr 2000 16:37:29 -0700 (PDT) (envelope-from jeremyp@pc0640.alcatel.com.au) Received: by border.alcanet.com.au id <115286>; Fri, 14 Apr 2000 09:37:44 +1000 From: Peter Jeremy Subject: Re: MLEN and crashes In-reply-to: <"from jdp"@polstra.com> To: John Polstra Cc: current@FreeBSD.ORG Message-Id: <00Apr14.093744est.115286@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0i Content-type: text/plain; charset=us-ascii References: <20000403084330.6A6DC483D@hcswork.hcs.de> <20000403023858.F21029@fw.wintelcom.net> <200004031622.JAA19715@vashon.polstra.com> <2000-04-03-18-34-19+trackit+sam@inf.enst.fr> Date: Fri, 14 Apr 2000 09:35:43 +1000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 3/04, John Polstra wrote: [don't allocate big structs on kernel stack] Many years ago, I wrote a tool that analysed stack requirements by parsing the assembler output from the compiler. It determined the stack frame requirements and built a call flow graph to determine total stack depth. It had some hooks to allow indirect function calls to be specified manually. It couldn't handle alloca() (and equivalents), but they were forbidden by the design standards. Anyone who does embedded work probably has something similar (or maybe better). It occurs to me that something along these lines would be quite useful for picking overly expensive (in stack space) subroutine threads within the kernel. (And maybe identifying areas where we could safely allow malloc'd structs to be made auto). The downside is that indirect function calls would need to be manually identified - which could be a significant amount of effort. What are other people's opinions on the usefulness of something like this? Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message