public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Gary Benson <gbenson@redhat.com>
To: Antoine Tremblay <antoine.tremblay@ericsson.com>,
	       Pedro Alves <palves@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 2/7] Move some integer operations to common.
Date: Mon, 21 Sep 2015 09:10:00 -0000	[thread overview]
Message-ID: <20150921091007.GA23767@blade.nx> (raw)
In-Reply-To: <55F6E5BC.7050006@ericsson.com>

Hi Antoine, Pedro,

Antoine Tremblay wrote:
> On 09/14/2015 05:24 AM, Gary Benson wrote:
> > Antoine Tremblay wrote:
> > > On 09/11/2015 01:16 PM, Antoine Tremblay wrote:
> > > > On 09/11/2015 10:24 AM, Gary Benson wrote:
> > > > > Please don't introduce "#ifdef GDBSERVER" conditionals into
> > > > > common code, I spent some time removing them.  I know I
> > > > > didn't get them all, but the remaining two are on my hit
> > > > > list.
> > > > 
> > > > Humm what is the issue that makes this a bad idea if I may ?
> > 
> > The way the common code is built is currently kind of weird and
> > ugly.  Even though the code is shared, there's still places you
> > have to do the same work twice, for example if you add a new .c or
> > .h file to common, for example, you have to add it to both GDB's
> > and gdbserver's Makefiles.  If you add stuff that needs configure
> > checks, you have to add those twice too.  Also we build gnulib
> > twice.  Also, the way the compiler is invoked means that you can
> > accidentally #include GDB- or gdbserver-specific headers in common
> > code.  It's all very error-prone.
> > 
> > For the future we'd like to move the common code into its own
> > toplevel directory with it's own Makefile, it's own ./configure,
> > etc.  It would be built once, to a libgdbcommon.a or something
> > that GDB and gdbserver would statically link.  We can't do that
> > if gdb/{common,nat,target} have conditional code.
> 
> Ok, thanks for clarifying this for me.
> 
> So if there were a libgdbcommon I would need to include bfd into it
> and make it a requirement of that lib so that both GDB and GDBServer
> can use it.
> 
> So I've made bfd.h a requirement of GDBServer, and when there will
> be a libgdbcommon we can have the whole lib as a requirement there.
> 
> See patch v2 in next mail...

I don't think this will be acceptable.  If I understand correctly,
gdbserver supports some platforms that GDB (and BFD) does not, and
this patch would prevent gdbserver being built on those platforms.
Even if I'm wrong here, I've previously found it useful to build
gdbserver alone, and I think this would break that too.

Pedro knows more about these kinds of setups, I've copied him in.

Thanks,
Gary

-- 
http://gbenson.net/

  parent reply	other threads:[~2015-09-21  9:10 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-11 12:13 [PATCH 0/7] Support tracepoints and software breakpoints on ARM aarch32-linux in GDBServer Antoine Tremblay
2015-09-11 12:13 ` [PATCH 1/7] Fix instruction skipping when using software single step " Antoine Tremblay
2015-09-11 12:13 ` [PATCH 2/7] Move some integer operations to common Antoine Tremblay
2015-09-11 14:24   ` Gary Benson
2015-09-11 17:16     ` Antoine Tremblay
2015-09-11 17:32       ` Antoine Tremblay
2015-09-14  9:24         ` Gary Benson
2015-09-14 15:20           ` Antoine Tremblay
2015-09-14 15:28             ` [PATCH 2/7 v2] " Antoine Tremblay
2015-09-21  9:10             ` Gary Benson [this message]
2015-09-21  9:16               ` [PATCH 2/7] " Pedro Alves
2015-09-21 17:49                 ` Antoine Tremblay
2015-09-22 16:06                   ` Doug Evans
2015-09-22 17:50                     ` Antoine Tremblay
2015-09-11 12:14 ` [PATCH 7/7] Support tracepoints and software breakpoints on ARM aarch32-linux in GDBServer Antoine Tremblay
2015-09-11 12:30   ` Eli Zaretskii
2015-09-11 12:43     ` Antoine Tremblay
2015-09-11 12:14 ` [PATCH 3/7] Support multiple breakpoint types per target " Antoine Tremblay
2015-09-11 12:14 ` [PATCH 4/7] Make breakpoint and breakpoint_len local variables " Antoine Tremblay
2015-09-11 12:14 ` [PATCH 5/7] Add support for software single step on ARM aarch32-linux " Antoine Tremblay
2015-09-14 11:00   ` Yao Qi
2015-09-14 12:41     ` Antoine Tremblay
2015-09-14 16:10       ` Yao Qi
2015-09-14 17:28         ` Antoine Tremblay
2015-09-15  7:22           ` Yao Qi
2015-09-15 12:33             ` Antoine Tremblay
2015-09-15 16:49               ` Antoine Tremblay
2015-09-11 12:14 ` [PATCH 6/7] Support conditional breakpoints on targets that can software single step " Antoine Tremblay
2015-09-14 10:33 ` [PATCH 0/7] Support tracepoints and software breakpoints on ARM aarch32-linux " Yao Qi
2015-09-14 13:23   ` Antoine Tremblay
2015-09-15 14:02     ` Yao Qi
2015-09-15 14:08       ` Antoine Tremblay
2015-09-23 20:40 [PATCH 2/7] Move some integer operations to common Doug Evans
2015-09-24 11:53 ` Antoine Tremblay

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=20150921091007.GA23767@blade.nx \
    --to=gbenson@redhat.com \
    --cc=antoine.tremblay@ericsson.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).