Skip site navigation (1)Skip section navigation (2)
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+trackit+sam@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: <http://docs.FreeBSD.org/cgi/mid.cgi?00Apr14.093744est.115286>