Re: Interface gdb with a embedded custom RTOS

Re: Interface gdb with a embedded custom RTOS

[Christophe PLANAT]

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

Re: Interface gdb with a embedded custom RTOS

[Quality Quorum]

On Thu, 5 Apr 2001, Christophe PLANAT wrote:

> 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 ?).

RTEMS is a RTOS, see http://www.rtems.com , you can dounload, build and 
run it on your standard PC (and on quite a few other embedded targets).

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

Here RTOS-land break usually means OS break - whole thing stops at the
breakpoint and switches control to stub, the only exception I know is
VxWorks, which has per task debugging mode, however, in the system 
debuggin mode it will behave as most other RTOSes do.

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

There are countless ways to start an RTOS, e.g. I am usually doing it
using BOOTP.

I would suggest building RTOS and trying debugger on the thing, it will
immediately clarify a lot of things you are askig about.

> 
> Thanks a lot for your help
> 
> Christophe Planat
> 

Thanks,

Aleksey

Re: Interface gdb with a embedded custom RTOS

[Christophe PLANAT]

qqi@world.std.com 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. I suppose it may answer a few
> questions you have.
>
> Thanks,
>
> Aleksey
>
>
> On Fri, 30 Mar 2001, Christophe PLANAT wrote:
>
> > Hi everybody,
> >
> > I'm using GDB and searching how to interface GDB with a custom EMBEDDED
> > OS in a USER APPLICATION.
> >
> > Question :
> > ----------
> >
> > Does the GDB thread control is dedicated to address MULTI-THREAD TARGETS
> >
> > (such as multi-thread ISS) on which one may download any user program
> > (not threaded) - fig 1 ?
> >
> >                 OR
> >
> > Does the GDB thread control is dedicated to address MULTI-THREAD
> > PROGRAMS downloaded in any ISS (not threaded) - fig 2 ?
> >
> > fig 1 :
> >             |--|
> > |------|    |  |      |--------------------|
> > | GDB  |  thread API  | MULTI-THREADED ISS |<---- download (thru GDB)
> > |------|    |  |      | | th1 | th2 | ...  |      some not threaded user
> >
> >             |--|      |--------------------|      pgm
> >
> >
> > fig 2 :
> >             |--|
> > |------|    |  |      |-----------------|
> > | GDB  |  thread API  |  Some  ISS      |<---- download (thru GDB)
> > |------|    |  |      |  (not threaded) |      MULTI-THREADED user pgm
> >             |--|      |-----------------|
> >
> >
> >
> > In case of fig 2 where an embedded RTOS controls a user application, how
> > does the GDB thread controller controls the RTOS ?
> >
> > For instance, the binary loaded by GDB includes the user application and
> > the RTOS in the code. The user program is started by GDB. In the main,
> > the OS is initialized, started and the user threads are then created and
> > started. How does GDB discuss with the OS :
> >
> >   - the OS is stopped at specifics points and out of context calls are
> > done by the user in order to get threads info, set breakpoints in
> > threads ...
> >      or
> >   - the OS never dies when started by the user main() and discuss with
> > GDB. Ths OS is never stopped
> >
> > I don't understand how the debugger may discuss with an OS started by
> > the user application, be able to break thread, get kernel info, withtout
> > stopping the OS ?
> >
> > I need some info in order to implement the API between the debugger and
> > the OS ?
> >
> >
> > Context for instance:
> > ---------------------
> >
> > A multi-threaded program uses an embedded kernel (say myos). The
> > processor is represented by a simulator (not threaded) targeted in GDB.
> >
> > I analysed GDB 5.0 files concerning the thread control (thread.c,
> > gdbthread.h. and hpux-thread.c, nachos-thread.c  examples) but I don't
> > see how does the debugger (which controls the simulator) interfaces with
> >
> > the OS kernel which is at the application level -- running on the
> > simulator (fig 2) ?
> >
> > What I understand (is it true ?) :
> >
> > GDB core uses internally a thread controller (thread.c). The user writes
> >
> > an OS dependant file [for instance myos-thread.c] and primitivers
> > pointed by GDB core through the init_myos_thread_ops structure. Each
> > primitive may use OS dependant primitives listed in gdbthread.h.
> >
> > But in this scheme, how does GDB interface with the embedded myos kernel
> >
> > (fig 2) which is linked to the application program ? GDB (and ISS) are
> > not at the same level that myos kernel ?
> >
> > Thanks a lot if you can help me on this very important subject.
> >
> > 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 |
> > ----------------------------------------------------------------------
> >
> >
> >

Thanks a lot for this invaluable information. I am going to analyse your
documents.

Christophe

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

Interface gdb with a embedded custom RTOS

[Christophe PLANAT]

Hi everybody,

I'm using GDB and searching how to interface GDB with a custom EMBEDDED
OS in a USER APPLICATION.

Question :
----------

Does the GDB thread control is dedicated to address MULTI-THREAD TARGETS

(such as multi-thread ISS) on which one may download any user program
(not threaded) - fig 1 ?

                OR

Does the GDB thread control is dedicated to address MULTI-THREAD
PROGRAMS downloaded in any ISS (not threaded) - fig 2 ?

fig 1 :
            |--|
|------|    |  |      |--------------------|
| GDB  |  thread API  | MULTI-THREADED ISS |<---- download (thru GDB)
|------|    |  |      | | th1 | th2 | ...  |      some not threaded user

            |--|      |--------------------|      pgm


fig 2 :
            |--|
|------|    |  |      |-----------------|
| GDB  |  thread API  |  Some  ISS      |<---- download (thru GDB)
|------|    |  |      |  (not threaded) |      MULTI-THREADED user pgm
            |--|      |-----------------|



In case of fig 2 where an embedded RTOS controls a user application, how
does the GDB thread controller controls the RTOS ?

For instance, the binary loaded by GDB includes the user application and
the RTOS in the code. The user program is started by GDB. In the main,
the OS is initialized, started and the user threads are then created and
started. How does GDB discuss with the OS :

  - the OS is stopped at specifics points and out of context calls are
done by the user in order to get threads info, set breakpoints in
threads ...
     or
  - the OS never dies when started by the user main() and discuss with
GDB. Ths OS is never stopped

I don't understand how the debugger may discuss with an OS started by
the user application, be able to break thread, get kernel info, withtout
stopping the OS ?

I need some info in order to implement the API between the debugger and
the OS ?


Context for instance:
---------------------

A multi-threaded program uses an embedded kernel (say myos). The
processor is represented by a simulator (not threaded) targeted in GDB.

I analysed GDB 5.0 files concerning the thread control (thread.c,
gdbthread.h. and hpux-thread.c, nachos-thread.c  examples) but I don't
see how does the debugger (which controls the simulator) interfaces with

the OS kernel which is at the application level -- running on the
simulator (fig 2) ?

What I understand (is it true ?) :

GDB core uses internally a thread controller (thread.c). The user writes

an OS dependant file [for instance myos-thread.c] and primitivers
pointed by GDB core through the init_myos_thread_ops structure. Each
primitive may use OS dependant primitives listed in gdbthread.h.

But in this scheme, how does GDB interface with the embedded myos kernel

(fig 2) which is linked to the application program ? GDB (and ISS) are
not at the same level that myos kernel ?

Thanks a lot if you can help me on this very important subject.

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

Re: Interface gdb with a embedded custom RTOS

[Quality Quorum]

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. I suppose it may answer a few
questions you have.

Thanks,

Aleksey
 

On Fri, 30 Mar 2001, Christophe PLANAT wrote:

> Hi everybody,
> 
> I'm using GDB and searching how to interface GDB with a custom EMBEDDED
> OS in a USER APPLICATION.
> 
> Question :
> ----------
> 
> Does the GDB thread control is dedicated to address MULTI-THREAD TARGETS
> 
> (such as multi-thread ISS) on which one may download any user program
> (not threaded) - fig 1 ?
> 
>                 OR
> 
> Does the GDB thread control is dedicated to address MULTI-THREAD
> PROGRAMS downloaded in any ISS (not threaded) - fig 2 ?
> 
> fig 1 :
>             |--|
> |------|    |  |      |--------------------|
> | GDB  |  thread API  | MULTI-THREADED ISS |<---- download (thru GDB)
> |------|    |  |      | | th1 | th2 | ...  |      some not threaded user
> 
>             |--|      |--------------------|      pgm
> 
> 
> fig 2 :
>             |--|
> |------|    |  |      |-----------------|
> | GDB  |  thread API  |  Some  ISS      |<---- download (thru GDB)
> |------|    |  |      |  (not threaded) |      MULTI-THREADED user pgm
>             |--|      |-----------------|
> 
> 
> 
> In case of fig 2 where an embedded RTOS controls a user application, how
> does the GDB thread controller controls the RTOS ?
> 
> For instance, the binary loaded by GDB includes the user application and
> the RTOS in the code. The user program is started by GDB. In the main,
> the OS is initialized, started and the user threads are then created and
> started. How does GDB discuss with the OS :
> 
>   - the OS is stopped at specifics points and out of context calls are
> done by the user in order to get threads info, set breakpoints in
> threads ...
>      or
>   - the OS never dies when started by the user main() and discuss with
> GDB. Ths OS is never stopped
> 
> I don't understand how the debugger may discuss with an OS started by
> the user application, be able to break thread, get kernel info, withtout
> stopping the OS ?
> 
> I need some info in order to implement the API between the debugger and
> the OS ?
> 
> 
> Context for instance:
> ---------------------
> 
> A multi-threaded program uses an embedded kernel (say myos). The
> processor is represented by a simulator (not threaded) targeted in GDB.
> 
> I analysed GDB 5.0 files concerning the thread control (thread.c,
> gdbthread.h. and hpux-thread.c, nachos-thread.c  examples) but I don't
> see how does the debugger (which controls the simulator) interfaces with
> 
> the OS kernel which is at the application level -- running on the
> simulator (fig 2) ?
> 
> What I understand (is it true ?) :
> 
> GDB core uses internally a thread controller (thread.c). The user writes
> 
> an OS dependant file [for instance myos-thread.c] and primitivers
> pointed by GDB core through the init_myos_thread_ops structure. Each
> primitive may use OS dependant primitives listed in gdbthread.h.
> 
> But in this scheme, how does GDB interface with the embedded myos kernel
> 
> (fig 2) which is linked to the application program ? GDB (and ISS) are
> not at the same level that myos kernel ?
> 
> Thanks a lot if you can help me on this very important subject.
> 
> 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 |
> ----------------------------------------------------------------------
> 
> 
> 

Re: Interface gdb with a embedded custom RTOS

[Eli Zaretskii]

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.

Re: Interface gdb with a embedded custom RTOS

[qqi]

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