From: Stephen Smith <ischis2@home.com>
To: Elena Zannoni <ezannoni@cygnus.com>
Cc: Andrew Cagney <ac131313@cygnus.com>,
GDB patches <gdb-patches@sourceware.cygnus.com>,
Kevin Buettner <kevinb@cygnus.com>
Subject: Re: shared libraries and a remote target
Date: Wed, 18 Jul 2001 12:13:00 -0000 [thread overview]
Message-ID: <3B55E008.E2D4651@home.com> (raw)
In-Reply-To: <15189.59080.526458.935802@krustylu.cygnus.com>
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 <grin>
>
> The configure.tgt patch should be submitted separately, because it is
> not logically related to the shared library issue.
>
Will do!
>
> Thanks
> Elena
>
next prev parent reply other threads:[~2001-07-18 12:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-18 10:54 Stephen Smith
2001-07-18 11:44 ` Elena Zannoni
2001-07-18 12:13 ` Stephen Smith [this message]
2001-07-19 10:31 ` Stephen Smith
2001-07-19 15:18 ` Resubmital of: " Stephen Smith
2001-07-19 17:57 ` Elena Zannoni
2001-07-19 22:12 ` Stephen Smith
2001-07-20 12:02 ` Elena Zannoni
2001-07-20 17:26 ` Andrew Cagney
2001-07-20 9:52 ` Improved patch: " Stephen Smith
2001-07-20 11:10 ` Kevin Buettner
2001-07-20 17:17 ` Re-submit: " Stephen Smith
2001-07-20 17:52 ` Andrew Cagney
2001-07-23 0:22 ` Stephen Smith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3B55E008.E2D4651@home.com \
--to=ischis2@home.com \
--cc=ac131313@cygnus.com \
--cc=ezannoni@cygnus.com \
--cc=gdb-patches@sourceware.cygnus.com \
--cc=kevinb@cygnus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox