GDB commands

[Guillaume MENANT]

Hello,

I am trying to do a wrapper between GDB (which will be controlled by
Eclipse) and another protocol (specific debug protocol of a SPARC) and I
don't know which GDB command is mandatory for Eclipse. I've seen the
commands handled by the "sparc-stub.c" file but I wonder if it's
sufficient. For example, the "sparc-stub.c" doesn't handle the 's'
command which is obviously mandatory according to this page :
http://sources.redhat.com/gdb/onlinedocs/gdb_33.html#SEC679

Thanks (sorry for my english, i'm french)

--

Guillaume MENANT

[Guillaume MENANT]

Can't we know which command is mandatory ? I'm assuming that m, M, c, s, g, and G are mandatory but i'm not sure.

Guillaume MENANT wrote:

Hello,

I am trying to do a wrapper between GDB (which will be controlled by
Eclipse) and another protocol (specific debug protocol of a SPARC) and I
don't know which GDB command is mandatory for Eclipse. I've seen the
commands handled by the "sparc-stub.c" file but I wonder if it's
sufficient. For example, the "sparc-stub.c" doesn't handle the 's'
command which is obviously mandatory according to this page :
http://sources.redhat.com/gdb/onlinedocs/gdb_33.html#SEC679

Thanks (sorry for my english, i'm french)

--

Guillaume MENANT

Guillaume MENANT wrote:

>
> Can't we know which command is mandatory ? I'm assuming that m, M, c, s,
> g, and G are mandatory but i'm not sure.

I doubt a complete list is available. Off the top of my head, you need
vCont (and don't need c and s). You also need zN/ZN -- without breakpoints,
debugging is of no interest.

- Volodya

[Guillaume MENANT]

Why vCont and not c and s (to be more accurate, I want to debug embedded applications)?

Vladimir Prus wrote:

Guillaume MENANT wrote:

>
> Can't we know which command is mandatory ? I'm assuming that m, M, c, s,
> g, and G are mandatory but i'm not sure.

I doubt a complete list is available. Off the top of my head, you need
vCont (and don't need c and s). You also need zN/ZN -- without breakpoints,
debugging is of no interest.

- Volodya

Guillaume MENANT wrote:

>
> Why vCont and not c and s (to be more accurate, I want to debug embedded
> applications)?

Should you ever want threading support, you'll find that combination of
c, s and Hc packets has various bugs. For single-threaded target, it
does not matter, but even if you have single-threaded application, it might
change ;-)

- Volodya

[Michael Snyder-3]

On Fri, 2007-11-23 at 14:05 +0300, Vladimir Prus wrote:
> Guillaume MENANT wrote:
>
> >
> > Can't we know which command is mandatory ? I'm assuming that m, M, c, s,
> > g, and G are mandatory but i'm not sure.
>
> I doubt a complete list is available. Off the top of my head, you need
> vCont (and don't need c and s).

I don't see how that is true -- you can still control a target
using c and s rather than using vCont...


> You also need zN/ZN -- without breakpoints,
> debugging is of no interest.

Neither is this true -- breakpoints can be set the old fashioned
way using memory read/write and trap instructions.

[Michael Snyder-3]

On Fri, 2007-11-23 at 01:37 -0800, Guillaume MENANT wrote:
> Can't we know which command is mandatory ? I'm assuming that m, M, c, s, g,
> and G are mandatory but i'm not sure.

Sorry, didn't really understand your question at first.

I'm afraid we have not really sat down and tried to list
which commands are mandatory in recent times.

Many of the commands are designed to be optional (and of course,
any target-side gdb agent is required to quietly ignore any
command that it does not understand).

However, a number of commands can be used as substitutes for
one another.  Hence it is hard to say that one particular command
is "manditory", given that it can be replaced by another command.

Let me make an attempt, and please realize that I am
doing this "off the top of my head".

1) You need a way to read and write memory.  There are
several candidates, one being the original 'm' and 'M',
another being the newer 'x' and 'X' (binary encoded).

2) You need a way to read and write registers.  Again there
are several possible ways, for instance the original pair of
commands 'g' and 'G' (read/write entire register set), another
the more recent 'p' and 'P' (read/write individual register).

3) You need a way to control execution.  As mentioned, there is
the original pair of commands 's' and 'c' (step and continue),
and there is a newer set of commands built around the string
"vCont"

Of the many other command sequences, most can be considered optional
depending on what extra functionality you require (eg. if you need
multi-thread debugging).  But at this point I would have to advise
you to implement the above subset, then try debugging and see what
happens.

Cheers,
Michael

[Michael Snyder-3]

On Mon, 2007-11-26 at 14:22 -0500, Daniel Jacobowitz wrote:

> On Mon, Nov 26, 2007 at 11:01:47AM -0800, Michael Snyder wrote:
> > 1) You need a way to read and write memory.  There are
> > several candidates, one being the original 'm' and 'M',
> > another being the newer 'x' and 'X' (binary encoded).
>
> Just 'X', no 'x'; 'x' would be a logical addition but no one's been
> round to it.
>
> All the rest of what Michael's written looks correct to me.  You can
> get by with very few packets... but if you want a useful debugging
> stub, you may need more.
>
> I suspect '?' is mandatory.

Ah, yes.   ;-)

On Monday 26 November 2007 21:52:34 Michael Snyder wrote:

> On Fri, 2007-11-23 at 14:05 +0300, Vladimir Prus wrote:
> > Guillaume MENANT wrote:
> >
> > >
> > > Can't we know which command is mandatory ? I'm assuming that m, M, c, s,
> > > g, and G are mandatory but i'm not sure.
> >
> > I doubt a complete list is available. Off the top of my head, you need
> > vCont (and don't need c and s).
>
> I don't see how that is true -- you can still control a target
> using c and s rather than using vCont...

If the target is multi-threaded, vCont is much better idea. And given
that implementing vCont is about as much work as c/s/Hc, it's probably
better to just implement vCont even for single-threaded target.

> > You also need zN/ZN -- without breakpoints,
> > debugging is of no interest.
>
> Neither is this true -- breakpoints can be set the old fashioned
> way using memory read/write and trap instructions.

Yes, you're right.

- Volodya

[Daniel Jacobowitz-2]

On Mon, Nov 26, 2007 at 11:01:47AM -0800, Michael Snyder wrote:
> 1) You need a way to read and write memory.  There are
> several candidates, one being the original 'm' and 'M',
> another being the newer 'x' and 'X' (binary encoded).

Just 'X', no 'x'; 'x' would be a logical addition but no one's been
round to it.

All the rest of what Michael's written looks correct to me.  You can
get by with very few packets... but if you want a useful debugging
stub, you may need more.

I suspect '?' is mandatory.


--
Daniel Jacobowitz
CodeSourcery

[Guillaume MENANT]

Michael Snyder-3 wrote:

On Mon, 2007-11-26 at 14:22 -0500, Daniel Jacobowitz wrote:
> On Mon, Nov 26, 2007 at 11:01:47AM -0800, Michael Snyder wrote:
> > 1) You need a way to read and write memory.  There are
> > several candidates, one being the original 'm' and 'M',
> > another being the newer 'x' and 'X' (binary encoded).
>
> Just 'X', no 'x'; 'x' would be a logical addition but no one's been
> round to it.
>
> All the rest of what Michael's written looks correct to me.  You can
> get by with very few packets... but if you want a useful debugging
> stub, you may need more.
>
> I suspect '?' is mandatory.

Ah, yes.   ;-)

Thanks a lot for your answers. For now, I handle m, M, c, S, g, G, z, Z, vFlashWrite, vFlashErase and vFlashDone.