GDB's remote protocol: rCommand

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: 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

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: 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

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]

"J.T. Conklin" wrote:

> >>>>> "Stephen" == Stephen Smith <ischis2@home.com> writes:
> 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.

Thanks, I will look for the patch and may come back with questions.

>
> 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.
>

No, I propose (if we add this feature which would normally be turned off), item 4 be sent'
prior to sending this query.  If item 4 is not supported, then this wouldn't be supported either.

Comments on latency appear below.

>
> 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.

I don't think that would happen.  If I read the code correctly, this is the high level function is what gets
called if the user manually load loads the symbol table using the "add-symbol-file filename address " command in
the console.  It drills down into the correct low level target interface that you are referring to.

The problem here is that the remote protocol makes no mention of the low-level-interface to iterate over. As far
as remote.c is concerned, it doesn't know (or should I state that it doesn't appear to know/care).  That is why I
am proposing using the supported generic interface which will then drill down to the specific interface.

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

It will only come into play if three things happen:
   a) shared library support is enabled (default is disabled for speed reasons)
   b) item 4 needs to be supported.
   c) item 1 needs to be supported.

> 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.

I'm going to comment on this with my comments on the next item if you don't mind.

> 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.

I agree, if I was writing an extension for debugging on my host processor, but I am not.  I was
asked to my the solution process/file format independent by one person on this list - I will look
later.

Second, remote.c is target independent and I am attempting to keep the proposed implementation
as such.

Because of restrictions on the project that I am on, I can't put extraneous code in my executable
that is why we are using a gdb server.  This is keeping me from using magic symbols for getting this
to work.

Another thing, this solves the problem where the target OS loads the shared libraries before the code
gets a chance to run and before any of those (missing) magic breakpoints, memory reads, etc. would
even get hit.

Lastly, because the default would be off, the network/serial traffic would be the same as the
current implementation.

sps