From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Smith To: Elena Zannoni Cc: Andrew Cagney , GDB patches , Kevin Buettner Subject: Re: shared libraries and a remote target Date: Wed, 18 Jul 2001 12:13:00 -0000 Message-id: <3B55E008.E2D4651@home.com> References: <3B55CD58.13771694@home.com> <15189.59080.526458.935802@krustylu.cygnus.com> X-SW-Source: 2001-07/msg00451.html Elena Zannoni wrote: > Stephen Smith writes: > > I am re-submitting the patch contained in this email. The the last of the discussion is at > > http://sources.redhat.com/ml/gdb/2001-03/msg00234.html > > > > and the original patch submittal is at > > > > http://sources.redhat.com/ml/gdb-patches/2001-04/msg00185.html > > > > The patches still apply cleanly to the development tree - I tried this morning. > > > > Thanks > > sps > > > > Hi Stephen, thanks for your submission. > > Did you get a copyright assignment? One of your earlier > messages indicated that you were having troubles getting one. > It is all done! I even have the document back from the FSF! > > A few comments (sorry to be picky, but these are the rules). Your > patch doesn't fully follow the gnu coding standards. Comments > shouldn't be in c++ style. Variable names should not be using mixed > upper and lower case, use '_' to separate words instead. I see a few > missing white spaces before '('. Don't use 'extern' in .c files: does > remote.c already include top.h? > > Instead of using add_symbol_file_command, you should use > symbol_file_add, which is already exported (this would take > symfile.[ch] out of the picture). See its usage in other gdb files. > I believe this would be ok for your purposes. > Thanks for the comments. I will work on that. > > I am not clear on why we need the option to be set at gdb startup. > Could it be done with a set command by the user, after gdb has started? > This would avoid the need for initializationBlock, I think. > I initialized the variable so that it had a known value when gdb starts up. I had proposed that in the original proposal. > > I cannot really comment on the remote protocol side of things, that's > Andrew's baby. Or on shared libraries, that would be Kevin's. > I will wait > > The configure.tgt patch should be submitted separately, because it is > not logically related to the shared library issue. > Will do! > > Thanks > Elena >