This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Multi thread Debugging
- To: Fabrice Gautier <Fabrice_Gautier at sdesigns dot com>
- Subject: Re: [ECOS] Multi thread Debugging
- From: Jonathan Larmour <jlarmour at redhat dot co dot uk>
- Date: Fri, 25 Aug 2000 19:38:34 +0100
- CC: "Ecos-List \(E-mail\)" <ecos-discuss at sourceware dot cygnus dot com>
- Organization: Red Hat UK Ltd.
- References: <8AE4B526B977D411841F00A0CC334020052C2A@cuz-exchange.sdesigns.net>
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