Re: [ECOS] Multi thread Debugging

[Nick Garnett <nickg at cygnus dot co dot uk>]

Fabrice Gautier <Fabrice_Gautier@sdesigns.com> writes:

=> A bit more on the subject...

=> However If I compare the context saved in interrupt_end and the one on
=> HAL_TRHEAD_SWITCH_CONTEXT are quite different:
=> 
=> In interrupt_end the reg parameter point to the somewhere in the stack where
=> saved values appears in this order: (regs[0] should be edi if i read
=> corretly, the register from edi to eax are pushed by a pusha instruction)
=> 
=> edi 
=> esi
=> ebp
=> esp  (the one when entering the irq ie: regs+0x20 ) 
=> ebx
=> edx
=> ecx
=> eax 
=> Vector number
=> eip 
=> cs
=> 
=> At this point we can see this does not look like  a HAL_SavedRegister
=> structure while interrupt end does a set_save_context of that.
=> 
=> The registers saved by the HAL_THREAD_SWITCH_CONTEXT are also saved on the
=> stack.
=> The stack_ptr point to a HAL_SavedRegister structure so we have:
=> 
=> esp
=> next_context
=> ebp
=> ebx
=> esi
=> edi
=> 
=> If I'm not wrong in anything this means that :
=> 
=> 1/ The HAL_SavedRegister structure does not contain all the information
=> needed by the debugger. 
=> 
=> 2/ In any case the real thread switch occurs in the
=> HAL_THREAD_SWITCH_CONTEXT. But when this thread switch is caused by an irq,
=> we would like the debugger to report the point in the thread where the IRQ
=> occured. In the case of a thread switch not caused by an IRQ we may consider
=> reporting the thread as "interrupted" by the call to Cyg_Scheduler::unlock.
=> In this later case the information saved by the HAL_THREAD_SWITCH_CONTEXT
=> macro is not enought but many registers(eax,ebx,ecx,edx) do not need to be
=> saved in a C function call, and eip can be found on the stack (as the
=> Cyg_Sheduler::unlock return eip value) 
=> 
=> 3/ The get_saved_context function is buggy: when the saved_context member is
=> null (means the thread switch was not caused by an IRQ) it should
=> reconstruct a valid context using stack_ptr. In fact this is the
=> HAL_THREAD_GET_SAVED_REGISTERS macro that is buggy. So this is a i386
=> specific bug. (Good news!)
=> 
=> 4/ The HAL_GET_GDB_REGISTERS macro (in fact the corresponding function) is
=> buggy : it should transmit to gdb the saved context passed as the second
=> argument. A priori another i386 pc specific bug (Good news!)
=> 
=> Any thought about this? 
=> 

All your observations are correct. The main problem is that thread
saved contexts and interrupt saved contexts are different. In all
other HALs they are the same. I suspect that the simplest fix for now
is to change the format of the HAL_SavedRegisters structure to echo
that pushed by "pusha" and replace the "movl"s in context.S with
"pusha" and "popa". Then most references to this structure will work
as intended (give or take a few fixes elsewhere). Pushing/popping the
full register set on a i386 is not very expensive, so this will
probably not impact performance at all.


Basically, the PC port needs some work to bring it up to scratch with
the other ports and to fix lots of minor problems like these.


-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK