From mboxrd@z Thu Jan 1 00:00:00 1970 From: Elena Zannoni To: Stephen Smith Cc: Elena Zannoni , Andrew Cagney , GDB patches , Kevin Buettner Subject: Re: shared libraries and a remote target Date: Fri, 20 Jul 2001 12:02:00 -0000 Message-id: <15192.36315.396037.634008@krustylu.cygnus.com> References: <3B55CD58.13771694@home.com> <15189.59080.526458.935802@krustylu.cygnus.com> <3B575CCC.E4B5E759@home.com> <15191.36790.456922.418332@krustylu.cygnus.com> <3B57BDE9.82F6B5EB@home.com> X-SW-Source: 2001-07/msg00517.html 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