This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Interface gdb with a embedded custom RTOS
- To: Christophe PLANAT <christophe dot planat at st dot com>
- Subject: Re: Interface gdb with a embedded custom RTOS
- From: Quality Quorum <qqi at world dot std dot com>
- Date: Fri, 30 Mar 2001 10:01:58 -0500
- cc: gdb at sources dot redhat 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 |
> ----------------------------------------------------------------------
>
>
>