From: Fabrice Gautier <Fabrice_Gautier@sdesigns.com>
To: 'Jonathan Larmour' <jlarmour@redhat.co.uk>
Cc: "Ecos-List (E-mail)" <ecos-discuss@sourceware.cygnus.com>
Subject: RE: [ECOS] Multi thread Debugging
Date: Fri, 25 Aug 2000 12:06:00 -0000 [thread overview]
Message-ID: <8AE4B526B977D411841F00A0CC334020052C2B@cuz-exchange.sdesigns.net> (raw)
> -----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
next reply other threads:[~2000-08-25 12:06 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-08-25 12:06 Fabrice Gautier [this message]
-- strict thread matches above, loose matches on Subject: below --
2000-09-01 14:18 Fabrice Gautier
2000-08-31 18:54 Fabrice Gautier
2000-09-01 3:12 ` Nick Garnett
2000-08-31 15:31 Fabrice Gautier
2000-09-01 2:55 ` Nick Garnett
2000-08-31 3:56 Fabrice Gautier
2000-08-30 19:56 Fabrice Gautier
2000-08-31 4:15 ` Nick Garnett
2000-08-30 16:39 Fabrice Gautier
2000-08-25 11:18 Fabrice Gautier
2000-08-25 11:38 ` Jonathan Larmour
2000-08-23 14:53 Fabrice Gautier
2000-08-24 7:17 ` Jonathan Larmour
2000-08-21 19:15 Fabrice Gautier
2000-08-15 12:00 Fabrice Gautier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8AE4B526B977D411841F00A0CC334020052C2B@cuz-exchange.sdesigns.net \
--to=fabrice_gautier@sdesigns.com \
--cc=ecos-discuss@sourceware.cygnus.com \
--cc=jlarmour@redhat.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).