This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: shared libraries and a remote target
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.
> 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.