From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christophe PLANAT To: gdb@sources.redhat.com Subject: Interface gdb with a embedded custom RTOS Date: Fri, 30 Mar 2001 05:55:00 -0000 Message-id: <3AC48F6E.B10720D7@st.com> X-SW-Source: 2001-03/msg00323.html 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 | ----------------------------------------------------------------------