| To: | Steve Lord <lord@xxxxxxx> |
|---|---|
| Subject: | Re: Large Stack Usage in One More Function |
| From: | Andi Kleen <ak@xxxxxxx> |
| Date: | Tue, 27 Aug 2002 19:37:59 +0200 |
| Cc: | Andi Kleen <ak@xxxxxxx>, Danny Cox <danscox@xxxxxxxxxxxxxx>, XFS Mailing List <linux-xfs@xxxxxxxxxxx> |
| In-reply-to: | <1030469638.16575.42.camel@xxxxxxxxxxxxxxxxxxxx> |
| References: | <1030467482.1611.14.camel@wiley> <1030467882.16697.28.camel@xxxxxxxxxxxxxxxxxxxx> <20020827192704.A27671@xxxxxxxxxxxxxxxx> <1030469638.16575.42.camel@xxxxxxxxxxxxxxxxxxxx> |
| Sender: | linux-xfs-bounce@xxxxxxxxxxx |
| User-agent: | Mutt/1.3.22.1i |
On Tue, Aug 27, 2002 at 12:33:58PM -0500, Steve Lord wrote: > On Tue, 2002-08-27 at 12:27, Andi Kleen wrote: > > gcc isn't very smart in that unfortunately. All local variables no matter > > if in a subscope > > or not or being dead for most of the function or not contribute the stack > > frame. > > The only way to get a separate stack frame is to either use alloca() or a > > different > > function. > > > > -Andi > > Thanks Andi, looks like breaking up the ioctl function would be the > best way to fix this then. Trick is to put the separate functions after the main ioctl, otherwise it'll break again for those people who ignore all words of reason and compile their kernel with -O3. -O3 auto inlines functions and you would get the same problem again. Fortunately it can only inline when the inlinee occurs before the first call of it. -Andi |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Large Stack Usage in One More Function, Steve Lord |
|---|---|
| Next by Date: | re[2]: Detected potential for stack overflows, stack left: 796 bytes, Greg Freemyer |
| Previous by Thread: | Re: Large Stack Usage in One More Function, Steve Lord |
| Next by Thread: | Re: Large Stack Usage in One More Function, Keith Owens |
| Indexes: | [Date] [Thread] [Top] [All Lists] |