This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Interface gdb with a embedded custom RTOS

Hi everybody,

I'm using GDB and searching how to interface GDB with a custom EMBEDDED

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 ?


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 ...
  - 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 :  | STMicroelectronics             |
| Phone : +33 04 76 92 68 82        | 850, rue Jean-Monnet           |
| Fax   : +33 04 76 92 50 94        | BP 16 - 38921 Crolles - France |

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]