From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Snyder To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Remote symbol look-up (resubmission) Date: Mon, 14 May 2001 14:34:00 -0000 Message-id: <3B004F51.4C9DC055@cygnus.com> References: <3AFC20A5.700ACFAF@cygnus.com> <3AFCA688.5060904@cygnus.com> <3B002163.D17BFA0E@cygnus.com> <3B004215.5040502@cygnus.com> X-SW-Source: 2001-05/msg00314.html Andrew Cagney wrote: [snip] > >> because the symbol file wasn't, in its self, useful to the target. The > >> qSymbol without arguments indicated new symbols were available. > > > > > > The symbol file could be useful to the target. For instance, we could > > specify to GDB which symbol file was to be used for the lookup. This > > would be consistent with the usage in the original thread-db spec from Sun. > > You've lost me here. > > Are you saying that there is going to need to be an extra parameter (the > shared library name) added to the target->gdb symbol request on Solaris? No, I'm saying it could potentially be useful to pass back the filename. Not that I think it is necessary. The underlying mechanism that would use this method on Solaris has a symbol-file-name argument. We don't currently use it. Someday we might. Just keeping the option open. > That would make it: > > qSymbol: [ : ] > > >> However, if you think the target should be notified of each new symbol > >> file then I'd rather see protocol go back to ``[qQ]SymbolFile:'' > >> followed by ``[qQ]Symbol::'' rather than the very subtlely > >> different ``QSymbol'' vs ``qSymbol''. > > > > > > I'll be glad to go back to that syntax. > > If it can be justified. > > Remember, it is really important to get these protocol changes right. > Unlike gdb internals, this is an external interface and once defined is > largely set in concrete. I am passing the filename because I believe it could be potentially useful. In my present implementation I do not use it. But that's just one implementation. As you point out, once its in it's hard to change. It would be a pity to take it out, and then later discover that we needed it in a different implementation. But just tell me what you want, and I will do it. Michael