Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: yao@codesourcery.com
Cc: gdb-patches@sourceware.org
Subject: Re: [patch] Move common macros to i386-common.h
Date: Wed, 23 Feb 2011 21:35:00 -0000	[thread overview]
Message-ID: <201102232117.p1NLHdhA015543@glazunov.sibelius.xs4all.nl> (raw)
In-Reply-To: <4D649A89.6040909@codesourcery.com> (message from Yao Qi on Wed,	23 Feb 2011 13:26:33 +0800)

> Date: Wed, 23 Feb 2011 13:26:33 +0800
> From: Yao Qi <yao@codesourcery.com>
> 
> On 02/13/2011 09:40 PM, Mark Kettenis wrote:
> > I'm just back from a 3+-week holiday.  I'm not buying into the "share more
> > stuff between gdb and gdbserver" mantra yet.  Please hold off on this
> > until
> > I've gotten caught up with my mail and had a chance to think about all this.
> 
> Mark,
> Do you ever have a change to look at this patch?  I am inclined to
> rename i386-common.h to i386-dbg-reg.h, since it is really about debug
> registers.

OK, here we go.  I don't have an issue with this diff per-se, but more
with the direction this is going.  A long time ago, gdb and gdbserver
shared a lot of code.  The gdbserver code could only be built on a
limited set of platforms though.  As a result gdbserver builds ended
up being broken often because of changes made to only gdb.  That's one
of the reasons why we split the two codebases.  Now, years later,
people are moving in the other direction again, and I'm worried it
will bring back the problems we had in the past.

I'm particularly worried about changes I'll make myself.  My primary
development platform is OpenBSD which isn't supported by gdbserver.
So I won't be building the gdbserver code, so I won't notice any
problems my diffs (and other people's diffs) will introduce in
gdbserver.

Sharing architecture-specific #define's is probably fine.  Sharing
some simple basec support functions may also be ok.  But I don't think
sharing more complicated code (such as the code manipulating the i386
debug registers) is a good idea.

Mark


  reply	other threads:[~2011-02-23 21:19 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-13  9:58 Yao Qi
2011-02-13 13:40 ` Mark Kettenis
2011-02-17  6:36   ` Yao Qi
2011-02-17  6:41     ` Joel Brobecker
2011-02-17 18:15       ` Jan Kratochvil
2011-02-23  5:36   ` Yao Qi
2011-02-23 21:35     ` Mark Kettenis [this message]
2011-02-24  4:32       ` Yao Qi
2011-02-24  5:11       ` Joel Brobecker
2011-02-28 18:12       ` Tom Tromey
2011-03-11  6:39 ` [try 2nd, patch] Move common macros to i386-dbg-reg.h Yao Qi
2011-03-29  7:54   ` Yao Qi
2011-04-07 14:07     ` Yao Qi
2011-04-07 15:54       ` Mark Kettenis
2011-04-11  2:01         ` Yao Qi
2011-04-13 17:05           ` Joel Brobecker
2011-04-13 18:48             ` Jan Kratochvil
2011-04-14  8:05             ` Yao Qi
2011-04-25 11:03             ` Yao Qi

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=201102232117.p1NLHdhA015543@glazunov.sibelius.xs4all.nl \
    --to=mark.kettenis@xs4all.nl \
    --cc=gdb-patches@sourceware.org \
    --cc=yao@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