James Carlson wrote: > Jonathan Adams writes: >> On Thu, Feb 26, 2009 at 03:11:04PM -0500, James Carlson wrote: >>>> The tool Ed mentioned is a new dcmd command: ::stackinfo (available since >>>> Nevada build 102), which shows kernel thread stack usage. >>> I'm talking about kmdb's stack itself. When that explodes, all is >>> lost. >> There *is* a stack checking mode in the compiler, which we could probably >> turn >> on. The only catches is we'd have to implement the backend support, and >> an unknown performance degradation. > > It also seems to be SPARC only. > >> Since it's based on guard pages, >> I *think* it would only effect routines which allocate more than a page >> (or just adds a blind read of the new stack pointer). Might be something >> to investigate. > > Possibly. I was mostly hoping for a static check, as that'd be the > simplest and most reliable for the specific cases I'm concerned about. > > I think your previous suggestion of grepping out the %rsp manipulation > is probably the best answer here. > lint claims to sniff out "error-prone stacks" - but that might mean anything. However - lint would be the right place to put a static check for huge automatics. A good threshold would be "if greater than our no-man's land" since that is where SIGSEGV gives way to weirdness.
I would think a small program ought to be able to derive, machine independently, the sizes of all the automatics in a .o compiled with -g, since debuggers need to know about such things. But I don't grok the output you get from dump(1) on the stabs sections. Oh well... John
