Re: GDB's remote protocol: My proposed extention

[jtc@redback.com (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