From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Garnett To: ecos-discuss@sourceware.cygnus.com Subject: Re: [ECOS] Multi thread Debugging Date: Thu, 31 Aug 2000 04:15:00 -0000 Message-id: References: <8AE4B526B977D411841F00A0CC334020052C35@cuz-exchange.sdesigns.net> X-SW-Source: 2000-08/msg00370.html Fabrice Gautier 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