Re: shared libraries and a remote target

Elena Zannoni
2001-07-20T12:02:00Z

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