----- Ursprüngliche Nachricht -----
Von: N. Coesel
Gesendet am: 26 Aug 2011 13:26:47
> I've been reading this thread for a while and it
> makes me wonder if there is some kind of tool
> which can analyze the code and determine the
> stack usage? I think this may be a safer route
> than to depend on a real-time stack check. The
> big question is: what do you do when the stack
> overflows? Just resetting the MCU is probably not
> an option so you'll have to add extra code to
> handle such an 'exception'. That does not seem very trivial to me.
Stack usage is a dynamic thing and happens at real-time.
Unless you code a benchmarck that always executes
exactly the same way, there is no way to determine stack
usage.
Some minor, small projects might be analyzeable, but for the
majority, it's up to you to guess and hope :)
----- Ursprüngliche Nachricht -----
Von: Radu Rendec
Gesendet am: 26 Aug 2011 13:54:46
> 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.
Yes, in this case, building a CRC over the area of the stack when
switching from, and checkign it when switching to, is the only option.
It will safely detect any corruption and refuse to continue the thread with
corrupted stack.
>> 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.
I didn't find a way for it too.
IMHO, it would be a good idea to make this available for the bigger
MSPs, since they have large enough flash to hold complex code,
including an OS that implements this kind of safety features.
> 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.
The problem is that even if it is reprogrammed,
only decrements by a push/call would be detected.
When the SP is moved down for local variables, it simply gets a new
value and will possibly skip the trigger value.
>> 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 :)
Indeed, slow code isn't why you program an MCU (however, some people
seem to think it doesn't matter - writing their code as if it were a
WIndows program)
And indeed, stack overflow shouldn't ever happen in a released product
(or else the programmer has failed to do his job properly).
So this kind of detection should only be needed during development.
However, bugs happen :(
JMGross
------------------------------------------------------------------------------
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
