Re: Interface gdb with a embedded custom RTOS

[Quality Quorum <qqi@world.std.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