Xref: utzoo comp.unix.questions:29754 comp.unix.internals:2417 comp.unix.programmer:1418 comp.lang.c:37528 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!snorkelwacker.mit.edu!ai-lab!gnu.ai.mit.edu!goehring From: goehring@gnu.ai.mit.edu (Not Marc Spencer) Newsgroups: comp.unix.questions,comp.unix.internals,comp.unix.programmer,comp.lang.c Subject: Re: Unix Stack Frame Questions Message-ID: Date: 25 Mar 91 16:37:09 GMT References: <125@epic.epic.com> Sender: news@ai.mit.edu Reply-To: goehring@gnu.ai.mit.edu Distribution: na Organization: Department of Tautological Pleonasms and Superfluous Redundancies Department Lines: 28 In-reply-to: tan@epic.epic.com's message of 22 Mar 91 23:43:43 GMT In article <125@epic.epic.com> tan@epic.epic.com (Andy Tan) writes: 1. Is it right to assume that the address of the last automatic variable is the bottom of stack frame ? it is not right to assume that there is a stack frame, and some compilers aren't going to put autos in the frame even if a frame exists since they can be more cheaply handled with registers. 2. How come save_state[2], which stores the Stack Pointer for SunOS 4.x, is far away from the assumed stack bottom ? Note: save_state[14], which stores the SP for SunOS 3.x, is very close to the assumed stack bottom. on a risc system with register windows some or all of your context might not even be in memory (if i understand some risc systems' usage of register windows correctly). every cpu is going to have varying stack frame format(s), assuming the cpu enforces one at all, and OS and compiler vendors are more than happy to create oddball parameter passing and stack frame conventions. what you appear to be doing is horribly non-portable and might as well be written in assembly; at least then it will be obvious that it's non-portable. :-) -- Help stamp out vi in our lifetime! Scott Goehring goehring@gnu.ai.mit.edu On exile in Indianapolis, IN