From owner-freebsd-current Sat Apr 15 1:41:44 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 476E637BFD8 for ; Sat, 15 Apr 2000 01:41:40 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <115235>; Sat, 15 Apr 2000 18:42:02 +1000 Content-return: prohibited From: Peter Jeremy Subject: Re: MLEN and crashes In-reply-to: <3694.955716608@critter.freebsd.dk> <200004141348.JAA56212@lakes.dignus.com> To: Poul-Henning Kamp , rivers@dignus.com Cc: John Polstra , current@FreeBSD.ORG Message-Id: <00Apr15.184202est.115235@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0i Content-type: text/plain; charset=us-ascii References: <00Apr14.093744est.115286@border.alcanet.com.au> <3694.955716608@critter.freebsd.dk> Date: Sat, 15 Apr 2000 18:41:59 +1000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 2000-Apr-14 23:40:53 +1000, Poul-Henning Kamp 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 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