This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]