From: Pedro Alves <palves@redhat.com>
To: lgustavo@codesourcery.com
Cc: "'gdb-patches@sourceware.org'" <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Share more common target structures between gdb and gdbserver
Date: Tue, 30 Jul 2013 17:48:00 -0000 [thread overview]
Message-ID: <51F7FC4E.3050604@redhat.com> (raw)
In-Reply-To: <51E595A0.6090500@codesourcery.com>
On 07/16/2013 07:49 PM, Luis Machado wrote:
> Hi,
>
> While doing some research about the remote fork following feature, i
> noticed there was some duplication of target data structures for GDB and
> gdbserver.
>
> This patch moves the shareable code/data structures to
> common/target-common.* and makes both GDB and gdbserver target files
> reference the header common/target-common.h.
>
> Makefiles and other files have been adjusted accordingly.
I'd very much prefer avoiding "common" in file names, instead
naming the files for what they contain, not for the fact that they're
"common" to two programs (gdb, gdbserver) presently. I think of it
this way -- when we finally end up with only one backend (or one
backend using a foo-common.c file), I'd rather avoid
renaming these files to something else, because they're no longer
"common". Or, yet IOW, think of common/ as a library. Can you
imagine if all libraries in a distro named their implementation
files "foo-common.c" ? Because that's what should happen given
they're used by lots of programs, right? :-) The direction I prefer
is, when moving things to common/ we take the opportunity to split them
into smaller, more atomic, leaner units. E.g., that's how we ended up
with ptid.h/ptid.c, instead of inferior-common.h (or some such).
If the file is just a dumping ground of misc things, then let's at
least call it that. Say, target-misc.h or target-defs.h.
Otherwise, this looks good to me.
On 07/16/2013 07:49 PM, Luis Machado wrote:
> +++ b/gdb/common/target-common.h
> @@ -0,0 +1,153 @@
> +/* Interface between the debugger and target environments, including files
> + and processes, shared between GDB and gdbserver.
> +
> + Copyright (C) 1990-2013 Free Software Foundation, Inc.
> +
> + Contributed by Cygnus Support. Written by John Gilmore.
(I have absolutely nothing again John, but this shows how
"contributed by"/"written by" lines are a disservice to future
hackers, IMO. Lot's of code here that others wrote.)
--
Pedro Alves
next prev parent reply other threads:[~2013-07-30 17:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-16 18:49 Luis Machado
2013-07-22 17:18 ` Tom Tromey
2013-07-22 18:23 ` Luis Machado
2013-07-30 17:48 ` Pedro Alves [this message]
2013-07-30 18:11 ` Tom Tromey
2013-07-31 12:16 ` Pedro Alves
2013-07-31 15:22 ` Tom Tromey
2013-07-31 18:43 ` Luis Machado
2013-07-31 19:03 ` Pedro Alves
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=51F7FC4E.3050604@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=lgustavo@codesourcery.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