On Fri, 2011-08-26 at 13:12 +0200, JMGross wrote: > If the local array is still on the stack, the task switch code will detect > that the SP is out-of-bounds and act as if the guard code were > overwritten. (In my implementation, it will not detect which other > thread might have been affected, if at all)
True. But I was concerned about the case when the array is no longer on the stack (actually SP is no longer out-of-bounds) at the time when the thread switcher pops in. In this case the safety codes are intact, SP is not out-of-bounds, so you can't detect it. Yet data had been corrupted. > One really weird thought: > One could set up a second MSP that acts as a protected mode > supervisor. It is programmed through e.g. SPI by the applciation MSP > and sets access and limit breakpoints through JTAG. > If a breakpoint is hit (the SP is set lower than allowed, or whatever > condition is programmed by the multithreader) it will trigger a proper > interrupt (throug JTAG too, so it is an NMI). Of course it would be much better if the hardware could handle it. At first, I looked for a way to access/program the EEM from within the CPU, but apparently there isn't any. I guess it's only accessible through JTAG. Moreover, the EEM only supports comparing a register to a fixed value. Therefore, it should be "reprogrammed" each time the OS is switching context, because the SP bounds change. > Well, I think, if you need something like this, you should look for > a different processor instead, e.g. an embedded 80386. ;) > And JTAG is slow... I need it more for the development phase rather than production (look at the other post I made a few minutes ago). It might be acceptable to have a development board with 2 MSPs, but (as you pointed out as well) it's _slow_ and this is one thing I can't afford :) 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
