Re: Interface gdb with a embedded custom RTOS

[Christophe PLANAT <christophe dot planat at st dot com>]

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