This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 2/7] Move some integer operations to common.

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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]