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