Date: Sat, 15 Apr 2000 18:41:59 +1000 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: Poul-Henning Kamp <phk@critter.freebsd.dk>, rivers@dignus.com Cc: John Polstra <jdp@polstra.com>, current@FreeBSD.ORG Subject: Re: MLEN and crashes Message-ID: <00Apr15.184202est.115235@border.alcanet.com.au> In-Reply-To: <3694.955716608@critter.freebsd.dk> <200004141348.JAA56212@lakes.dignus.com> References: <00Apr14.093744est.115286@border.alcanet.com.au> <3694.955716608@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2000-Apr-14 23:40:53 +1000, Poul-Henning Kamp <phk@critter.freebsd.dk> wrote: >In message <00Apr14.093744est.115286@border.alcanet.com.au>, Peter Jeremy write >s: >>Many years ago, I wrote a tool that analysed stack requirements by >>parsing the assembler output from the compiler. ... >Commit it either as a general tool or as a kernel targeted tool >under src/tools. And the faster the better :-) I'll have to see if I can still find it. In any case, it was designed to handle M68K assembler from a Microtec compiler. It would need some re-work before it could work with FreeBSD. On 2000-Apr-14 23:49:58 +1000, Thomas David Rivers <rivers@dignus.com> wrote: > How did you address recursive functions, or were they also forbidden > by design standards? They were forbidden from memory. (Which will be a nuisance here). They would show up as loops in the call graph. Even if I can't find my previous code, the design of such a tool is fairly trivial (given the assembler, or a suitably patched compiler). The first part reads the assembler: When a function is defined, you note the local framesize and keep track of other stack pushes/pops to work out total stack requirements for the function. When a function is called, you output a triplet of caller, called function and stack usage. (From memory I cheated a bit and output caller/called pairs, with a separate maximum stack used line). This information should be fairly trivially available within the compiler as an alternative. The second part reads all the output from the first part and forms a call flow graph, generating maximum stack needs from each node. The top level node(s) give you the total stack needs. One reason for splitting it into two bits is to make it easier to add manual entries for indirect function calls. (Some of this `manual' work could be partially automated). Recursive calls (which there are a fair number of in the FreeBSD kernel) aren't that easily handled and would probably entail manual (or semi-automatic) editing. I'll have a go at a more detailed design (and see if I can find or re-implement it) if no-one else has one already. 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?00Apr15.184202est.115235>