Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Christophe PLANAT <christophe.planat@st.com>
To: qqi@world.std.com
Cc: gdb@sources.redhat.com
Subject: Re: Interface gdb with a embedded custom RTOS
Date: Thu, 05 Apr 2001 08:45:00 -0000	[thread overview]
Message-ID: <3ACC92D7.C1685CD@st.com> (raw)
In-Reply-To: <H00004920a3028a2@MHS>

qqi@world.std.com wrote:

> ----- Original Message -----
> From: Eli Zaretskii <eliz@is.elta.co.il>
> To: Quality Quorum <qqi@world.std.com>
> Cc: <gdb@sources.redhat.com>
> Sent: Sunday, April 01, 2001 4:51 AM
> Subject: Re: Interface gdb with a embedded custom RTOS
>
> >
> > On Fri, 30 Mar 2001, Quality Quorum wrote:
> >
> > > I put some documents, gdb patches and code implementing multithreaded
> > > support for RTEMS on my web site: http://world.std.com/~qqi under
> > > the heading of GDB remote protocol.
> >
> > Thanks for the URL.
> >
> > How is this related to what's currently in GDB?  If this document
> > describes what GDB does, it might serve as a useful source for updating
> > gdbint.texinfo.
>
> 1. This document describes what gdb does wrt single thread operations.
> 2. As far as I understand multi-threaded support over remote gdb protocol is
> mostly in the realm of wishfull thinking, so this document tries to fix it.
> 3. Reference implementation provides full blown working example to play with
> (along with a few general improvements, e.g. unifying remote and
> extended-remote targets in the single one, where exetended operations is an
> option).
> 4. My overall conclusion is that there are some serious limitations of gdb
> core wrt multi-threading support (BTW, that is why
> linux-threads implementation looks so screwy), which would not allow it be
> used effectively over remote gdb protocol.
>
> Thanks,
>
> Aleksey

After analysing your documents, I understand that RTEMS is embedded in a user
application on a board (right ?).

Does the user application launch the OS (I mean the main() which init RTEMS
kernel then creates threads and run them) or is it an other behavior model ?
In the case of an embedded kernel, I see 2 possible approaches :

 - by using an ISS, the OS+user_appli are downloaded by GDB in the ISS memory.
Then the program is run : init OS, creates and starts threads ...: In such case
how can GDB break a thread without breaking the OS ? Does GDB ask the OS to
stop a thread (in case of break) whereas the OS still run ? Or does GDB break
the thread directly (user debug info) and the OS too since the OS and the user
appli are the same code in fact ?

- by using an application board (no code downloaded). The OS is started at the
reset but never stopped (in ROM). I need more infos on the threading support in
such case

Thanks a lot for your help

Christophe Planat

--
----------------------------------------------------------------------
| Christophe PLANAT                 | Embedded Systems Technology    |
| Email : Christophe.Planat@st.com  | STMicroelectronics             |
| Phone : +33 04 76 92 68 82        | 850, rue Jean-Monnet           |
| Fax   : +33 04 76 92 50 94        | BP 16 - 38921 Crolles - France |
----------------------------------------------------------------------




       reply	other threads:[~2001-04-05  8:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <H00004920a3028a2@MHS>
2001-04-05  8:45 ` Christophe PLANAT [this message]
2001-04-05 14:20   ` Quality Quorum
     [not found] <H00004920a2ec543@MHS>
2001-04-02  1:42 ` Christophe PLANAT
2001-03-30  5:55 Christophe PLANAT
2001-03-30  7:02 ` Quality Quorum
2001-04-01  0:54   ` Eli Zaretskii
2001-04-01  9:26     ` qqi

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=3ACC92D7.C1685CD@st.com \
    --to=christophe.planat@st.com \
    --cc=gdb@sources.redhat.com \
    --cc=qqi@world.std.com \
    /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