Re: Interface gdb with a embedded custom RTOS

[Quality Quorum <qqi at world dot std dot com>]

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