From mboxrd@z Thu Jan 1 00:00:00 1970 From: jtc@redback.com (J.T. Conklin) To: Stephen Smith Cc: Andrew Cagney , GDB , Kevin Buettner , Michael Elizabeth Chastain Subject: Re: GDB's remote protocol: My proposed extention Date: Wed, 21 Mar 2001 15:59:00 -0000 Message-id: <5mofuuvlar.fsf@jtc.redback.com> References: <3AB6CB9A.C0883CD9@home.com> <3AB7867B.3D80F74A@cygnus.com> <3AB90BE2.B3878F54@home.com> X-SW-Source: 2001-03/msg00233.html >>>>> "Stephen" == Stephen Smith 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