Re: GDB's remote protocol: My proposed extention

[Stephen Smith <ischis2@home.com>]

"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