Date: Fri, 14 Apr 2000 09:35:43 +1000 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: John Polstra <jdp@polstra.com> Cc: current@FreeBSD.ORG Subject: Re: MLEN and crashes Message-ID: <00Apr14.093744est.115286@border.alcanet.com.au> In-Reply-To: <"from jdp"@polstra.com> References: <Pine.BSF.4.21.0004022118510.1442-100000@alphplex.bde.org> <20000403084330.6A6DC483D@hcswork.hcs.de> <20000403023858.F21029@fw.wintelcom.net> <200004031622.JAA19715@vashon.polstra.com> <2000-04-03-18-34-19%2Btrackit%2Bsam@inf.enst.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00Apr14.093744est.115286>