Re: [ECOS] Multi thread Debugging

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

Fabrice Gautier <Fabrice_Gautier@sdesigns.com> writes:

> Hi,
> 
> > -----Original Message-----
> > From: Nick Garnett [mailto:nickg@cygnus.co.uk]
> > Sent: Thursday, August 31, 2000 4:08 AM
> > To: ecos-discuss@sourceware.cygnus.com
> > Subject: Re: [ECOS] Multi thread Debugging
> > 
> > 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". 
> 
> I'm testing some changes like this. It seems to work with the HAL context.c
> test, but with a more complicated program I've some strange crash I didn't
> have before. 
> The program ends with an exception (SIGSEGV, SIGILL or SIGTRAP) and it seems
> this is during a thread switch. 

Are you able to see which instruction it is on, and what the register
contents are? These might give a clue to what is happening. 

> 
> I suspect that in some cases the changes I've made may be unsafe. I'm not
> sure if the switch context function have to be re-entrant it is safe to
> assume that a context switch can't be interrupted by another context switch?
>

It is possible for a thread in the middle of a switch to be
interrupted, but that will not cause a nested context switch to
happen. However, it is important to make sure that the SP is valid at
all times, and there is no useful data below it. Your code below looks
like it behaves correctly in this respect.

> One main difference between my new version and the current version is that
> the next context ptr is not saved as a part of the SavedRegisters structure.
> So this pointer is pushed on the stack (as a parameter for
> hal_thread_load_context) AFTER the current thread stack pointer has been
> saved. So if another context switch occurs at this time I suppose the saved
> context will be corrupted.

That should be OK, no switch should occur.

[snipped most code - it looks OK apart from the comment below]


> #---------------------------------------------------------------------------
> ---
> # hal_thread_load_context
> # Load thread context
> # : 4(%esp) (!= i386reg_next_context(%esp)) = address of sp of thread to
> execute
> # Note that this function is also the second half of
> hal_thread_switch_context
> # and is simply dropped into from it.
> #
> # %eax, %ecx, and %edx are ours to abuse.
>         
> FUNC_START(hal_thread_load_context)
> 
> #ifdef CYGHWR_HAL_I386_FPU	
> 	movl	%cr0, %eax
> 	orl	$0x8, %eax
> 	movl	%eax, %cr0
> #endif
> 	
>       movl  4(%esp),%eax # get new context ptr
> 	movl	(%eax),%esp
> 	popal   # unstack general registers
> 	popl %ebx # unstack vector (should be 0xdeaddead)
=============^^^^

This may be the problem, isn't EBX callee-saved? I would pop into EAX,
or
        addl $4,%esp

>         
>         ret
> 
 

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