[ECOS] eCos2 stack base corrupted?

[Jonathan Larmour]

NavEcos wrote:
> On Friday 03 January 2003 10:20 am, Fredrik Hederstierna wrote:
> 
>>I have done this, otherwise I wouldnt get this ASSERT.static.
>>
>>Its the stack _base_address_ (a member variable in the hardware thread
>>struct) that is trashed, not stack overflow that is the problem I believe.
>>I do not know if the threads are allocated at consecutive memory with the
>>stacks, I guess thread-structs are in the '.data' segment and the actual
>>stacks in the '.bss' section.
> 
> 
> Well, when you create a thread you specify a variable that is used for that 
> stack (usually an array of characters), you might want to see what other 
> variables are declared around the stack variable...

Actually the interesting bit is around the thread structure (the 
cyg_thread), not the stack.

> You can get a list of all your symbols in the order of where they are place in 
> your program with:
> 
> readelf -s YOUR_ECOS_EXECUTABLE | sort +1
> 
> NOTE: if you've declared your symbols "static" I am not sure it will work
> 
> And REMEMBER: stacks grow DOWN, not up.  So you usually start from the end of 
> your array, and work backward.
> 
> 
>>I seems like its just in the context-switch the crash occurs, when the
>>thread the scheduler wants to run got  bad stack address.
>>I found a thing I wonder about in the scheduler-code:
>>
>>In void Cyg_Scheduler::unlock_inner( cyg_ucount32 new_lock )
>>
>>               // Switch contexts
>>              HAL_THREAD_SWITCH_CONTEXT( &current->stack_ptr,
>>&next->stack_ptr );
>>
>>               // Worry here about possible compiler
>>                // optimizations across the above call that may try to
>>                // propogate common subexpresions.  We would end up
>>                // with the expression from one thread in its
>>                // successor. This is only a worry if we do not save
>>                // and restore the complete register set. We need a
>>                // way of marking functions that return into a
>>                // different context. A temporary fix would be to
>>                // disable CSE (-fdisable-cse) in the compiler.
>>
>>Can this be a problem?

Although I shouldn't give a categorical no, I'll say it anyway. No. :)

Jifl
-- 
eCosCentric       http://www.eCosCentric.com/       <info@eCosCentric.com>
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss