RE: [ECOS] Multi thread Debugging

RE: [ECOS] Multi thread Debugging

[Fabrice Gautier]

Again more thoughts about that.
(Sorry if i'm filling your mailboxes)

> [...]
> 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. 

> 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!)

I see a problem here. If we want to construct a valid context that can be
returned to the gdb stub, we need some memory. I see only two solutions for
this:

a/ Have a structure in the thread class that can contain this context.
b/ Allocate this structure on the stack just before switching thread - in
addition to the space already used to store the switch context 
c/ Have the same structure for the switch context and the full context, and
so construct the full context at every thread switch.

Providing that I've get it all right since the beginning, here are my though
about implemting such solutions

a/	Up: Is seems easy to implement.
	Downs: require a change for all archs and take extra memory.
b/	Up: Only needs to change i386 code
	Down: Less easy to implement, take extra memory on threads stacks
(but easy to  get rid of this Down when not in debug mode)
c/	Up: Maybe the more logical (same context for interrupt or thread
switch)
	Down: Probably less efficient for thread switching (and not easy to
change this when not in debug mode)


> 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!)

Another soultion could be not to return any context when saved_context is
null and to treat this specific case in the dbg_getthreadreg function. Such
a change would apply to all arch however.

One concern anyway is to know if the problem I experience only occur with
the i386 PC platform. 

For what I see, I think the same problem may occur in any arch where the
thread and interrupt contexts are different.

Thanks

A+

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 

RE: [ECOS] Multi thread Debugging

[Fabrice Gautier]

> -----Original Message-----
> From: Nick Garnett [ mailto:nickg@cygnus.co.uk ]
> Subject: Re: [ECOS] Multi thread Debugging
> 
> [snipped most code - it looks OK apart from the comment below]
> 
> 
> This may be the problem, isn't EBX callee-saved? I would pop into EAX,

Yes thats it!

In fact there is another place where i used ebx and i should not. I should
have use ecx instead. Replace very occurence of ebx by ecx in my changes and
it works perfectly now.

Well in fact thi only change the context stored by eCos, there is a bit more
work to do to get this context in gdb....

Thanks

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 

Re: [ECOS] Multi thread Debugging

[Nick Garnett]

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

Re: [ECOS] Multi thread Debugging

[Nick Garnett]

Fabrice Gautier <Fabrice_Gautier@sdesigns.com> writes:

> > -----Original Message-----
> > From: Nick Garnett [ mailto:nickg@cygnus.co.uk ]
> > 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". Then most references to this structure will work
> > as intended (give or take a few fixes elsewhere).
> 
> I fear this is not so simple.
> 
> There is a problem too with exception handling. This is critical because of
> the handling of the INT3 debug exception.
> 
> It seems that in the current design (refering to plf_stub.c) the register
> are saved to a structure when an INT3 occurs. And this structure does not
> match any other of our context structures...
> 
> Exception handling in the stub is not handled in the way the Interrupts
> are...(The exceptions are not handled by the kernel, only by the stub it
> seems)
> 

This is because the code in the stubs is derived from non-eCos sources
for supporting GDB, and is not fully integrated. It's not very clean
and we need to sort it out, but at present we don't have the resources
here to do it. 

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

RE: [ECOS] Multi thread Debugging

[Fabrice Gautier]

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. 

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?

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.


I post here the modifications I've made:

First the HAL_SavedRegisters structure:
=======================================

typedef struct 
{
    cyg_uint32  edi;
    cyg_uint32  esi;
    cyg_uint32  ebp;
    cyg_uint32  esp;                  
    cyg_uint32  ebx;
    cyg_uint32  edx;
    cyg_uint32  ecx;
    cyg_uint32  eax;    
    cyg_uint32  vector; // if saved on interrupt contains intr vector
    cyg_uint32  eip;
    cyg_uint32  arg1;   // cs (when intr) or parameter
    cyg_uint32  arg2;	// eflags (when intr) or parameter
} HAL_SavedRegisters;

*******************************************************

Then the context init routine:
==============================

//--------------------------------------------------------------------------
---
// Context Initialization
// Initialize the context of a thread.
// Arguments:
// _sp_ name of variable containing current sp, will be written with new sp
// _thread_ thread object address, passed as argument to entry point
// _entry_ entry point address.
// _id_ bit pattern used in initializing registers, for debugging.

#define HAL_THREAD_INIT_CONTEXT( _sparg_, _thread_, _entry_, _id_ )       \
    CYG_MACRO_START                                                       \
    register CYG_WORD* _sp_ = ((CYG_WORD*)((_sparg_) &~15));              \
    register HAL_SavedRegisters *_regs_;                                  \
                                                                          \
    /* The 'ret' executed at the end of hal_thread_load_context will  */  \
    /* use the last entry on the stack as a return pointer (_entry_). */  \
    /* Cyg_HardwareThread::thread_entry expects one argument at stack */  \
    /* offset 4 (_thread_). The (0xDEADBEEF) entry is the return addr */  \
    /* for thread_entry (which is never used).                        */  \
    *(--_sp_) = (CYG_WORD)(0);                                            \
    *(--_sp_) = (CYG_WORD)(0);                                            \
    *(--_sp_) = (CYG_WORD)(0);                                            \
    *(--_sp_) = (CYG_WORD)(0);                                            \
                                                                          \
    _regs_ = (HAL_SavedRegisters *)                                       \
               ((unsigned long)_sp_ - sizeof(HAL_SavedRegisters));        \
    _regs_->arg2   = (CYG_WORD)(_thread_);				  \
    _regs_->arg1   = (CYG_WORD)(0);				  \
    _regs_->eip	   = (CYG_WORD)(_entry_);				  \
    _regs_->vector = (CYG_WORD)(_id_);					  \
    _sp_-=4;								  \
    _regs_->esp    = (CYG_WORD) _sp_;                                     \
    _regs_->ebp    = (CYG_WORD)(_id_);                                    \
    _regs_->esi    = (CYG_WORD)(_id_);                                    \
    _regs_->edi    = (CYG_WORD)(_id_);                                    \
    _regs_->eax    = (CYG_WORD)(_id_);					  \
    _regs_->ebx    = (CYG_WORD)(_id_);                                    \
    _regs_->ecx    = (CYG_WORD)(_id_);					  \
    _regs_->edx    = (CYG_WORD)(_id_);                                    \
    (_sparg_)      = (CYG_ADDRESS) _regs_;                                \
    CYG_MACRO_END

*******************************************************

And the switch routine:
=======================

#---------------------------------------------------------------------------
---
# hal_thread_switch_context
# Switch thread contexts
# :     0(%esp) :     return address
# :     4(%esp) :     address of sp of next thread to execute
# :     8(%esp) :     address of sp save location of current thread
#
# %eax, %ecx, and %edx are ours to abuse.
        
FUNC_START(hal_thread_switch_context)
#        movl    4(%esp),%eax            # next context ptr
#        movl    8(%esp),%edx            # this context ptr

	popl %ebx  # save return eip
	popl %eax  # get next context ptr
	popl %edx  # get this context ptr

	# Save context
		
	pushfl		# save eflags
	pushw %cs	# save cs
	pushw 0		# and pad to 32 bits
	pushl %ebx	# save eip 
	pushl $0xdeaddead # push vector
	pusha		# push general registers
	
      # Save next context ptr in this context. Necessary because
      # hal_thread_load_context expects to find the ptr on the stack,
      # not in a register as on PPC. 
        
      # Store the context ptr
      movl    %esp,(%edx)
	        
      #push next context ptr as an argument to load context
	pushl %eax
	pushl	$0xdeadbeef # load_context return pointer, never used 
	
      # Now fall through to hal_thread_load_context
        
        
#---------------------------------------------------------------------------
---
# 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)
        
        ret

RE: [ECOS] Multi thread Debugging

[Fabrice Gautier]

> -----Original Message-----
> From: Nick Garnett [ mailto:nickg@cygnus.co.uk ]
> 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". Then most references to this structure will work
> as intended (give or take a few fixes elsewhere).

I fear this is not so simple.

There is a problem too with exception handling. This is critical because of
the handling of the INT3 debug exception.

It seems that in the current design (refering to plf_stub.c) the register
are saved to a structure when an INT3 occurs. And this structure does not
match any other of our context structures...

Exception handling in the stub is not handled in the way the Interrupts
are...(The exceptions are not handled by the kernel, only by the stub it
seems)

Thanks

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 

Re: [ECOS] Multi thread Debugging

[Nick Garnett]

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

RE: [ECOS] Multi thread Debugging

[Fabrice Gautier]

A bit more on the subject...

> -----Original Message-----
> From: Fabrice Gautier 
> Subject: RE: [ECOS] Multi thread Debugging
> 
> > -----Original Message-----
> > From: Jonathan Larmour [ mailto:jlarmour@redhat.co.uk ]
> > Subject: Re: [ECOS] Multi thread Debugging
> > 
> > The stack_ptr member is there for a different purpose than 
> > saved_context.
> > saved_context is for GDB debugging purposes only and 
> provides the full
> > context. AFAIK interrupt_end is the only place that stores 
> > the context in
> > saved_context.
> 
> In fact I've seen that when saved_context member is NULL, the 
> stack_ptr is used instead.

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? 

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 





> > This is interesting - it's not clear to me either how 
> > saved_context is set
> > if threads get rescheduled for any reason other than an interrupt.
> 
> It is not set at all. But get_saved_context get the registers 
> from stack_ptr.
>  
> > Is this a bug?
> 
> It doesn't seem 
>  
> > I wouldn't have thought this would have caused a problem on 
> the scale
> > Fabrice is seeing at any rate.
> 
> The problem may be elsewhere.
> 
> May be here: (Warning, this is i386 PC specific stuff now)
> 
> void hal_get_gdb_registers(target_register_t * d, 
> HAL_SavedRegisters * s)
> {
> 	int i ;
> 
> 	for (i = 0; i < NUMREGS; i++)
> 		d[i] = hal_pc_trap_registers[i] ;
> } 
> 
> This is seen in hal/i386/pc/current/src/plf_stub.c. Note how 
> this function does not use the 's' parameter while all we 
> need is in there. This is called in dbg_getthreadreg and 's' 
> would be either saved_context or stack_ptr.
> 
> I found another version of this function in 
> hal/i386/arch/current/src/i386_stub.c
> 
> #if 0
> void hal_get_gdb_registers(target_register_t * d, 
> HAL_SavedRegisters * s)
> {
> 	d[ESP] = s->esp ;
> 	d[ESP] = s->esp ;
> 	d[EBP] = s->ebp ;
> 	d[EBX] = s->ebx ;
> 	d[ESI] = s->esi ;
> 	d[EDI] = s->edi ;
> 	d[PC] = s->eip ;
> }
> #endif
> 
> This one looks better, but unfortunately there is no s->eip. 
> The HAL_SavedRegister doesn't have one. Unfortunate.
> 
> If someone know why this version has been discarded and what 
> the other is intented to do it sould be fun.
> 
> Thanks
> 
> A+
> 
> -- 
> Fabrice Gautier
> fabrice_gautier@sdesigns.com 
> 

RE: [ECOS] Multi thread Debugging

[Fabrice Gautier]

> -----Original Message-----
> From: Jonathan Larmour [ mailto:jlarmour@redhat.co.uk ]
> Subject: Re: [ECOS] Multi thread Debugging
> 
> 
> 
> The stack_ptr member is there for a different purpose than 
> saved_context.
> saved_context is for GDB debugging purposes only and provides the full
> context. AFAIK interrupt_end is the only place that stores 
> the context in
> saved_context.

In fact I've seen that when saved_context member is NULL, the stack_ptr is
used instead.
 

> This is interesting - it's not clear to me either how 
> saved_context is set
> if threads get rescheduled for any reason other than an interrupt.

It is not set at all. But get_saved_context get the registers from
stack_ptr.
 
> Is this a bug?

It doesn't seem 
 
> I wouldn't have thought this would have caused a problem on the scale
> Fabrice is seeing at any rate.

The problem may be elsewhere.

May be here: (Warning, this is i386 PC specific stuff now)

void hal_get_gdb_registers(target_register_t * d, HAL_SavedRegisters * s)
{
	int i ;

	for (i = 0; i < NUMREGS; i++)
		d[i] = hal_pc_trap_registers[i] ;
} 

This is seen in hal/i386/pc/current/src/plf_stub.c. Note how this function
does not use the 's' parameter while all we need is in there. This is called
in dbg_getthreadreg and 's' would be either saved_context or stack_ptr.

I found another version of this function in
hal/i386/arch/current/src/i386_stub.c

#if 0
void hal_get_gdb_registers(target_register_t * d, HAL_SavedRegisters * s)
{
	d[ESP] = s->esp ;
	d[ESP] = s->esp ;
	d[EBP] = s->ebp ;
	d[EBX] = s->ebx ;
	d[ESI] = s->esi ;
	d[EDI] = s->edi ;
	d[PC] = s->eip ;
}
#endif

This one looks better, but unfortunately there is no s->eip. The
HAL_SavedRegister doesn't have one. Unfortunate.

If someone know why this version has been discarded and what the other is
intented to do it sould be fun.

Thanks

A+

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 

RE: [ECOS] Multi thread Debugging

[Fabrice Gautier]

> -----Original Message-----
> From: Jonathan Larmour [ mailto:jlarmour@redhat.co.uk ]
> Subject: Re: [ECOS] Multi thread Debugging
> 
> 
> Fabrice Gautier wrote:
> > Si now I see that there is a saved context when there is an 
> > interrupt but
> > I don't understand how is the context saved when there is a 
> > thread switch.
> > 
> > The macro HAL_THREAD_SWITCH_CONTEXT let me think that there 
> > is something
> > saved in the stack_ptr member of the Threads while in 
> > interrupt_end it is
> > saved in the saved_context member.
> 
> The stack_ptr member is there for a different purpose than 
> saved_context.
> saved_context is for GDB debugging purposes only and provides the full
> context. AFAIK interrupt_end is the only place that stores 
> the context in
> saved_context.
> 
> This is interesting - it's not clear to me either how 
> saved_context is set
> if threads get rescheduled for any reason other than an interrupt.
> 
> Is this a bug?
> 
> I wouldn't have thought this would have caused a problem on the scale
> Fabrice is seeing at any rate.
> 
> > Then, I'v eseen in GDB that in order to get the information 
> > for each thread
> > it does a thread switch. How (where?) is a thread switch 
> > request from gdb
> > done in the Stub?
> 
> There is no thread switch in the stub. Look at
> kernel/VERSION/src/debug/dbg_gdb.cxx and specifically 
> dbg_threadlist(). It
> traverses the list of threads by following the thread list pointers.

Yes, okay.  This function works well for I can get the name and status of
each thread.
But in GDB, There is a switch_to_thread function called in the
info_threads_command in order to get the PC.
In fact I think GDB only try to do a stack frame switch in this function but
in fact the frame is always the same. It seems that the read_fp function
always return the same frame pointer. (And this is the one of the current
thread)

There is certainly a bug somewhere but I don't know if it is a GDB bug or a
eCos bug. 
I've already send a mail to the gdb mailing list but didnt get any answer.

Thanks
-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 

Re: [ECOS] Multi thread Debugging

[Jonathan Larmour]

Fabrice Gautier wrote:
> Si now I see that there is a saved context when there is an interrupt but
> I don't understand how is the context saved when there is a thread switch.
> 
> The macro HAL_THREAD_SWITCH_CONTEXT let me think that there is something
> saved in the stack_ptr member of the Threads while in interrupt_end it is
> saved in the saved_context member.

The stack_ptr member is there for a different purpose than saved_context.
saved_context is for GDB debugging purposes only and provides the full
context. AFAIK interrupt_end is the only place that stores the context in
saved_context.

This is interesting - it's not clear to me either how saved_context is set
if threads get rescheduled for any reason other than an interrupt.

Is this a bug?

I wouldn't have thought this would have caused a problem on the scale
Fabrice is seeing at any rate.

> Then, I'v eseen in GDB that in order to get the information for each thread
> it does a thread switch. How (where?) is a thread switch request from gdb
> done in the Stub?

There is no thread switch in the stub. Look at
kernel/VERSION/src/debug/dbg_gdb.cxx and specifically dbg_threadlist(). It
traverses the list of threads by following the thread list pointers.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

RE: [ECOS] Multi thread Debugging

[Fabrice Gautier]

> -----Original Message-----
> From: Jonathan Larmour [ mailto:jlarmour@redhat.co.uk ]
> Subject: Re: [ECOS] Multi thread Debugging
> 
> > 
> > And doing so I saw that the hwthread->saved_context member 
> > is always a NULL
> > pointer (for every thread and all the time)
> 
> Then you should probably be looking at interrupt_end in
> kernel/VERSION/src/intr/intr.cxx to see what's going on there - in
> particular, is the "regs" argument valid.
> 

AFAICS the argument seems valid. 

Si now I see that there is a saved context when there is an interrupt but  
I don't understand how is the context saved when there is a thread switch.

The macro HAL_THREAD_SWITCH_CONTEXT let me think that there is something
saved in the stack_ptr member of the Threads while in interrupt_end it is
saved in the saved_context member. 

Then, I'v eseen in GDB that in order to get the information for each thread
it does a thread switch. How (where?) is a thread switch request from gdb
done in the Stub? 

Thanks
-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 

Re: [ECOS] Multi thread Debugging

[Jonathan Larmour]

Fabrice Gautier wrote:
> 
> In order to workaround this problem I put a breakpoint in cyg_thread_create
> and I recorded every thread structures so I can watch them later.
> 
> And doing so I saw that the hwthread->saved_context member is always a NULL
> pointer (for every thread and all the time)

Then you should probably be looking at interrupt_end in
kernel/VERSION/src/intr/intr.cxx to see what's going on there - in
particular, is the "regs" argument valid.

> Is this normal? Is this is not structure used by the stub/gdb to access
> threads informations??

Remind us which target and platform you are using?

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

RE: [ECOS] Multi thread Debugging

[Fabrice Gautier]

Hi,

In order to workaround this problem I put a breakpoint in cyg_thread_create
and I recorded every thread structures so I can watch them later.

And doing so I saw that the hwthread->saved_context member is always a NULL
pointer (for every thread and all the time)

Is this normal? Is this is not structure used by the stub/gdb to access
threads informations??

Thanks

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 

> -----Original Message-----
> From: Fabrice Gautier [ mailto:Fabrice_Gautier@sdesigns.com ]
> Sent: Monday, August 21, 2000 7:14 PM
> To: Fabrice Gautier; Ecos-List (E-mail)
> Subject: RE: [ECOS] Multi thread Debugging
> 
> 
> Hi,
> 
> This problem is somewhat annoying... Am I the only one 
> experiencing it?
> 
> Thanks
> 
> Fabrice
> 
> > -----Original Message-----
> > From: Fabrice Gautier [ mailto:Fabrice_Gautier@sdesigns.com ]
> > Sent: Tuesday, August 15, 2000 11:59 AM
> > To: Ecos-List (E-mail)
> > Subject: [ECOS] Multi thread Debugging
> > 
> > 
> > Hi,
> > 
> > I've some problem with multi-thread debugging. 
> > 
> > I've 4 threads, I can see there state in the process window, 
> > but they all
> > have  the same instruction pointer (which is the running 
> > process instruction
> > pointer)
> > 
> > Thanks
> > -- 
> > Fabrice Gautier
> > fabrice_gautier@sdesigns.com 
> > 
> > 
> 

RE: [ECOS] Multi thread Debugging

[Fabrice Gautier]

Hi,

This problem is somewhat annoying... Am I the only one experiencing it?

Thanks

Fabrice

> -----Original Message-----
> From: Fabrice Gautier [ mailto:Fabrice_Gautier@sdesigns.com ]
> Sent: Tuesday, August 15, 2000 11:59 AM
> To: Ecos-List (E-mail)
> Subject: [ECOS] Multi thread Debugging
> 
> 
> Hi,
> 
> I've some problem with multi-thread debugging. 
> 
> I've 4 threads, I can see there state in the process window, 
> but they all
> have  the same instruction pointer (which is the running 
> process instruction
> pointer)
> 
> Thanks
> -- 
> Fabrice Gautier
> fabrice_gautier@sdesigns.com 
> 
> 

[ECOS] Multi thread Debugging

[Fabrice Gautier]

Hi,

I've some problem with multi-thread debugging. 

I've 4 threads, I can see there state in the process window, but they all
have  the same instruction pointer (which is the running process instruction
pointer)

Thanks
-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com