This is the mail archive of the
mailing list for the GDB project.
Re: [rfa/rfc] Build libcommon.a for gdb and gdbserver
- From: Tom Tromey <tromey at redhat dot com>
- To: Pedro Alves <pedro at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org, Yao Qi <yao at codesourcery dot com>
- Date: Thu, 03 Feb 2011 14:29:51 -0700
- Subject: Re: [rfa/rfc] Build libcommon.a for gdb and gdbserver
- References: <4D30E23F.email@example.com> <4D375F44.firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
Tom> I think gdb/configure is already pretty messy. It is more than 2000
Tom> lines of code. A few more for gdbserver aren't going to hurt much, IMO.
Pedro> As I said before, gdbserver is buildable without building gdb, even
Pedro> for targets that can't build gdb. How would you make it work?
I mentioned a couple ways upthread, but I think it doesn't matter any
Pedro> Many of the core structures and defines aren't shared yet between
Pedro> gdb and gdbserver. gdb has defs.h, and gdbserver has server.h.
Pedro> Ideally we'd pull the really common stuff into some header
Pedro> under common/. As is, there are incompatibilities. Take a
Pedro> look at the top of common/signals.c, for example.
Pedro> This is one of the reasons that I want to forbit gdb/common/ files
Pedro> from including things from gdb/. For the local patches we
Pedro> have that move stuff into gdb/common/ (independent effort from
Pedro> Yao's), we added an #ifdef GDBSERVER then #error in gdb/defs.h
Pedro> to catch that at compile time.
Pedro> (Before Yao came along, my plan was to clean up these
Pedro> header issues before considering building a common library.)
I understand now, thanks.
I am still not super fond of this, but seeing as I have no better idea,
I think you should go ahead. It will definitely be an improvement.