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: qqi at world dot std dot com
- Subject: Re: Interface gdb with a embedded custom RTOS
- From: Christophe PLANAT <christophe dot planat at st dot com>
- Date: Mon, 02 Apr 2001 10:41:37 +0200
- Cc: gdb at sources dot redhat dot com
- Organization: ST CR&D Crolles
- References: <H00004920a2ec543@MHS>
qqi@world.std.com wrote:
> 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 |
> > ----------------------------------------------------------------------
> >
> >
> >
Thanks a lot for this invaluable information. I am going to analyse your
documents.
Christophe
--
----------------------------------------------------------------------
| 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 |
----------------------------------------------------------------------