This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: RTOS awareness
Nick:
> We are not using a stub but a JTAG interface to the processor (ARM7
> core), can we still redirect the printf ?
Dunno. Although it's hardly a comparison, my Abatron unit for CPU32
can. When the target takes a particular trap with the registers set a
certain way, it'll snarf up the text string pointed at by one of the
registers and package it up n a 'O' packet--- thereby sending it to
the gdb display.
Don't see any reason why it couldn't be done for JTAG in the same way,
it's just a question of whether your JTAG interface vendor builds in
that functionality.
> How can you call a function form the GDB command line ?
Assuming you have a function like this in your application:
int foo (void);
(gdb) print foo()
will work. Other function signatures work as well, and gdb will
invoke the target's malloc() if necessary to make room for reference
arguments like strings. *Quite* cool and useful!
b.g.
>
> Thanks
>
> Nick
>
> On 6 Aug 2002 at 20:33, William A. Gatliff wrote:
>
> Date sent: Tue, 6 Aug 2002 20:33:50 -0500
> From: "William A. Gatliff" <bgat@billgatliff.com>
> To: Nicolas Moreau <nicolas@enttec.com>
> Copies to: gdb@sources.redhat.com
> Subject: Re: RTOS awareness
> Send reply to: bgat@billgatliff.com
>
> > Nick:
> >
> >
> > Pardon me from providing an incomplete answer, but you may also
> > consider just having some "helper functions" with your stub or
> > application that provide the needed functionality via printf()
> > (redirected to gdb's console, for example). You would call those
> > functions from gdb's command line, rather than mucking with gdb source
> > code. No gdb mods required.
> >
> > Just a thought. I think eCos (another RTOS) uses this technique.
> >
> >
> > b.g.
> >
> > On Wed, Aug 07, 2002 at 11:20:19AM +1000, Nicolas Moreau wrote:
> > > Hi
> > >
> > > I would like to write a UCOS II (embedded RTOS) awarness module for
> > > GDB to use on our embedded system. What I want to display is the
> > > data structure associated with each task, the display has to be in a
> > > user friendly format (no raw memory dump) Where can I start ? How
> > > can I extend the fucntionality of UCOS ? What source files should I
> > > be looking at ?
> > >
> > > Thanks
> > >
> > > Nick
> > >
> >
> > --
> > Bill Gatliff
> > bgat@billgatliff.com
> >
>
>
--
Bill Gatliff
bgat@billgatliff.com