Re: Interface gdb with a embedded custom RTOS

[Christophe PLANAT <christophe.planat@st.com>]

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