This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Multi thread Debugging


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]