Path: chuka.playstation.co.uk!scea!formica From: sumner@metrowerks.com (Joel Sumner) Newsgroups: scea.yaroze.programming.codewarrior Subject: Re: System memory Date: Mon, 11 Aug 97 21:02:32 GMT Organization: Metrowerks Lines: 30 Message-ID: <5snuct$dp61@scea> References: <01bc957d$ffb78880$9fbf43ce@wkwerner> <33d63ee2.2608036@news.scea.sony.com> <01bca2b9$a16f32c0$69bf43ce@wkwerner> <33E9982D.54A636C9@micronetics.com> NNTP-Posting-Host: jsumner2.metrowerks.com X-Newsreader: News Xpress 2.0 Beta #0 In article <33E9982D.54A636C9@micronetics.com>, Jim wrote: >Wayne K. Werner wrote: > >> The easiest form of stack checking I can see for the NY is to run your >> program in debug mode, stepping into each routine to the depth desired. Do >> a register dump to see what the value of the stack pointer is. > >I've not tryed this method but you could always write a macro called >STACK_CHECK >that would grab the sp and check it against a specific thresh hold Another method would be to write a known constant to the last "x" words of the stack (i.e. the lowest addresses of the stack). If those words ever change, then you know that your program has extended all the way to the end of the stack. You won't know exactly WHEN the program hit the end, but you at least know that it happend. This method is a bit more reliable than the above two because this macro can be placed anywhere (end of the main loop would be a good place, right before the VSyncWait or something) and it will always detect the stack corruption (assuming your program hasn't crashed yet). Once you know that the overrun occurs, then you can do more work to try and find it. You won't waste any time looking for the source of a stack corruption until you're positive that it actually happened. -Joel -------- PlayStation Debugger Dude Metrowerks