On Thu, 2011-08-25 at 12:21 +0200, JMGross wrote: > I had a similar problem but came up with a completely different solution. > When my (preemptive) multitasker creates a new thread, it reserves some > organizational space as well as the stack for the new > thread. > The orignaizational data is a linked list for all the threads and begins with > a guard code. The new stack space immediately follows and > ends with anothe rguard code. > When I switch threads, I check the guard codes. If they have been touched, > there is something wrong and the affected thread is killed > and then a 'thread stack error interrupt' is called for debugging purposes. > This way, maybe I don't know when exactly this happened, but it doesn't lower > overall performance and safely detects any stack > corruption. The code overhead is low too, as the checking is done on a > central place that is already called on a task switch. > And there's no way to recover from such a situation anyway. > And it doesn't need patching the compiler :)
Thanks for sharing this method! It looks really interesting and it's definitely worth considering it. I have only one question, though. Suppose you have a function that allocates let's say 40 bytes on the stack. An example could be declaring "char foo[40]" as a local variable. Let's say R1/SP is only a few bytes above the stack "bottom" before entering this function. When you enter the function, the guard code that is placed immediately before the stack space is now located somewhere in the middle of the stack space reserved for the "foo" variable. If the function only touches the first few bytes of "foo", it may "corrupt" data but still keep your guard codes intact. Then the thread switching code won't be able to detect this. Could this be possible or did I just misunderstand the procedure you're describing? Best regards, Radu Rendec ------------------------------------------------------------------------------ EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
