From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jonathan Larmour To: Fabrice Gautier Cc: "Ecos-List \(E-mail\)" Subject: Re: [ECOS] Multi thread Debugging Date: Fri, 25 Aug 2000 11:38:00 -0000 Message-id: <39A6BD2A.3152A89@redhat.co.uk> References: <8AE4B526B977D411841F00A0CC334020052C2A@cuz-exchange.sdesigns.net> X-SW-Source: 2000-08/msg00286.html 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