Re: GDB's remote protocol: rCommand

Re: GDB's remote protocol: rCommand

[Eli Zaretskii]

On Mon, 19 Mar 2001, Stephen Smith wrote:

> When reading chapter 13 of the gdb manual, the rcmd can be taken to mean one 
> of two things:
> 
> 1)  a command sent from the host machine to the target machine for the GDB server/stub to
> execute
> 
> 2)  a command sent from the target machine to the host machine for GDB to execute
> 
> Which is it supposed to be?

The former, of course.  The text before the table says:

    The host (GDB) sends COMMANDs, and the target (the debugging stub
    incorporated in your program) sends a RESPONSE.

This is to say, _all_ the commands in the table are sent from host to
target; the stab on the target only sends responses to those commands.

Please suggest how to make this point more clear in the manual.

Re: GDB's remote protocol: My proposed extention

[Stephen Smith]

> Stephen Smith wrote:
> >
> > When reading chapter 13 of the gdb manual, the rcmd can be taken to mean one
> > of two things:
> >
> > 1)  a command sent from the host machine to the target machine for the GDB server/stub to
> > execute
>
> This one.  All (well ok almost all) packets are GDB->target->GDB.
>
>         Andrew

Ok, I have been poking around in the GDB code like you suggested and here is my proposal for changes in the remote.c
file:

1)   Until this is working use an environment variable to turn on this feature * especially since I don't know how to do
it right - yet*

2)   Add a "qLibraries" general query.  This query would expect a response of the form "sharedLib1, address1;
sharedLib2, address2; sharedLib3, address3"

3)   For  each library/address pair in the return, call add_symbol_file_command() from symfile.c.
      Advantage is that this is a high level function and should be processor/coef/elf independent.

4)  Add a "qNewLibraries" general query which would return a `1` or a `0`.

What do you think?

BTW, I keep trying to get a copy of the GNU foundation copyright assignment document so that I can submit the patch when
I am done, haven't
heard a thing from them.  Any suggestions on that also?

sps

Re: GDB's remote protocol: rCommand

[Andrew Cagney]

Stephen Smith wrote:
> 
> When reading chapter 13 of the gdb manual, the rcmd can be taken to mean one
> of two things:
> 
> 1)  a command sent from the host machine to the target machine for the GDB server/stub to
> execute

This one.  All (well ok almost all) packets are GDB->target->GDB.

	Andrew

GDB's remote protocol: rCommand

[Stephen Smith]

When reading chapter 13 of the gdb manual, the rcmd can be taken to mean one 
of two things:

1)  a command sent from the host machine to the target machine for the GDB server/stub to
execute

2)  a command sent from the target machine to the host machine for GDB to execute

Which is it supposed to be?

sps
-- 
Stephen Smith
1955 E. Bluefield Ave.
Phoenix, AZ  85022
(602)971-9520

Re: GDB's remote protocol: My proposed extention

[J.T. Conklin]

>>>>> "Stephen" == Stephen Smith <ischis2@home.com> writes:
Stephen> Ok, I have been poking around in the GDB code like you
Stephen> suggested and here is my proposal for changes in the remote.c
Stephen> file:
Stephen>
Stephen> 1) Until this is working use an environment variable to
Stephen>    turn on this feature * especially since I don't know how
Stephen>    to do it right - yet*

Generally, the way the remote protocol is extended is that a new
command is added and that GDB probes for it's existance.  If the debug
agent doesn't support it, it returns an empty packet and GDB modifies
it's behavior accordingly.  Recently we've been adding knobs so these
new commands can be explicitly disabled or enabled or probed, but the
default is to probe for the feature.  I've got a pending patch for 
a "step-over-range" command that was submitted a month or so ago.  It
might be useful to check the gdb-patches archive for this.

Stephen> 2) Add a "qLibraries" general query.  This query would expect
Stephen>    a response of the form "sharedLib1, address1; sharedLib2,
Stephen>    address2; sharedLib3, address3"

When would GDB issue this command?  Whenever the target stops?  We
don't want to add latency to the protocol.

Stephen> 3) For each library/address pair in the return, call
Stephen>    add_symbol_file_command() from symfile.c.  Advantage is
Stephen>    that this is a high level function and should be
Stephen>    processor/coef/elf independent.

The flip side of this is that if this high level mechanism is used,
support for shared libraries over low level target interfaces will
decay and bit rot.

How will this new interface play with the existing remote shared
library support?


Stephen> 4) Add a "qNewLibraries" general query which would return a
Stephen>    `1` or a `0`.

Again, when will this command be issued?

Another issue is that the remote protocol does not handle dropped or
duplicate packets reliably.  The NewLibraries query implies the debug
agent keeps state.  We fudge things a bit with the breakpoint packets,
but I'm not sure we can do the same here.

Stephen> What do you think?

I prefer GDB using low level accesses (magic breakpoints, memory
reads, etc.) to support shared libraries over having support in the
debug agent.  Yes, there is going to be target-specific knowlege in
either solib-foo.c or in the debug agent, and it might be about the
same amount of code; but I like the agent to be as lean and mean as 
it can be to minimize the Heisenberg effect.  It also means that the
shared library support is going to work regardless of back end.

        --jtc

-- 
J.T. Conklin
RedBack Networks