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: Thu, 5 Apr 2001 17:20:21 -0400
- cc: gdb at sources dot redhat dot com
On Thu, 5 Apr 2001, Christophe PLANAT wrote:
> qqi@world.std.com wrote:
>
> > ----- Original Message -----
> > From: Eli Zaretskii <eliz@is.elta.co.il>
> > To: Quality Quorum <qqi@world.std.com>
> > Cc: <gdb@sources.redhat.com>
> > Sent: Sunday, April 01, 2001 4:51 AM
> > Subject: Re: Interface gdb with a embedded custom RTOS
> >
> > >
> > > On Fri, 30 Mar 2001, Quality Quorum 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.
> > >
> > > Thanks for the URL.
> > >
> > > How is this related to what's currently in GDB? If this document
> > > describes what GDB does, it might serve as a useful source for updating
> > > gdbint.texinfo.
> >
> > 1. This document describes what gdb does wrt single thread operations.
> > 2. As far as I understand multi-threaded support over remote gdb protocol is
> > mostly in the realm of wishfull thinking, so this document tries to fix it.
> > 3. Reference implementation provides full blown working example to play with
> > (along with a few general improvements, e.g. unifying remote and
> > extended-remote targets in the single one, where exetended operations is an
> > option).
> > 4. My overall conclusion is that there are some serious limitations of gdb
> > core wrt multi-threading support (BTW, that is why
> > linux-threads implementation looks so screwy), which would not allow it be
> > used effectively over remote gdb protocol.
> >
> > Thanks,
> >
> > Aleksey
>
> After analysing your documents, I understand that RTEMS is embedded in a user
> application on a board (right ?).
RTEMS is a RTOS, see http://www.rtems.com, you can dounload, build and
run it on your standard PC (and on quite a few other embedded targets).
> Does the user application launch the OS (I mean the main() which init RTEMS
> kernel then creates threads and run them) or is it an other behavior model ?
> In the case of an embedded kernel, I see 2 possible approaches :
>
> - by using an ISS, the OS+user_appli are downloaded by GDB in the ISS memory.
> Then the program is run : init OS, creates and starts threads ...: In such case
> how can GDB break a thread without breaking the OS ? Does GDB ask the OS to
> stop a thread (in case of break) whereas the OS still run ? Or does GDB break
> the thread directly (user debug info) and the OS too since the OS and the user
> appli are the same code in fact ?
Here RTOS-land break usually means OS break - whole thing stops at the
breakpoint and switches control to stub, the only exception I know is
VxWorks, which has per task debugging mode, however, in the system
debuggin mode it will behave as most other RTOSes do.
> - by using an application board (no code downloaded). The OS is started at the
> reset but never stopped (in ROM). I need more infos on the threading support in
> such case
There are countless ways to start an RTOS, e.g. I am usually doing it
using BOOTP.
I would suggest building RTOS and trying debugger on the thing, it will
immediately clarify a lot of things you are askig about.
>
> Thanks a lot for your help
>
> Christophe Planat
>
Thanks,
Aleksey