Re: shared libraries and a remote target

[Elena Zannoni <ezannoni at cygnus dot com>]

Stephen Smith writes:
 > Elena Zannoni wrote:
 > 
 > > Looks much better thanks.
 > >
 > >  > I didn't change the call to symbol_file_add instead of add_symbol_file_command since that
 > >  > would mean inserting duplicate code into gdb to do the parsing of the input string.
 > >  >
 > >
 > > Actually, I assume you added the qLibraries packet, so you can control
 > > the format of the response, right? Can it be changed?  The command
 > > line functions (*_command) should be used only from the CLI.  The
 > > grand plan is to separate all the CLI code and put it into the cli
 > > subdirectory, where it won't be accessible from other parts of gdb.
 > > So, it would be better if you could manipulate the response to be
 > > better suited for the symbol_file_add command.  Actually you can see
 > > how that function is invoked from the shared libraries files, and
 > > maybe do something similar as well.
 > 
 > Actually, some of my internal co-workers are so allergic to changes in gdbserver
 > that I would rather do something in the patch. [Thinking out load].  Adding more
 > overhead to the traffic over the wire cause a couple of other developers heartburn.  It
 > would also mean writing code to do essentially the same thing as the *_command
 > function because it already parses the string and then calls symbol_file_add.  Since calling
 > that function isn't what is wanted from an architectural perspective, why don't I "copy" the
 > code to remote.c (renaming the function in the process) and then then symfile patches
 > won't be needed and the code should be about the same size.

Stephen, sorry, while I can understand that it is hard to revisit
design decisions, I don't think that is a reasonable motivation.
Anyway, I think we are getting a little ahead of ourselves, because
nobody has commented on the actual remote protocol change yet.  So
let's wait on that. It looks to me like the reply packets deviates a
bit from the standard, but I am not the maintainer for that.

 > 
 > > I still wonder about the need for startup options, though. The code
 > > would be simpler if there was a command to enable/disable this
 > > feature.  Since this feature works only for remote targets, it
 > > wouldn't make sense if one is running GDB natively. I think of startup
 > > options as something that is always going to work.
 > 
 > Ok, I can agree.  Now that you have convinced me, how do I do it.  The reason that I
 > coded the switch was because I couldn't figure out how to add a command that would only
 > get used in the remote code.
 > 

Ok. As Kevin said in his reply, look at uses of add_cmd. That's the
usual way to do this. There should be plenty of other examples in gdb
for you to get a template for its usage.


Elena