[rfa/rfc] Build libcommon.a for gdb and gdbserver
Yao Qi
yao@codesourcery.com
Thu Feb 24 03:58:00 GMT 2011
On 02/24/2011 12:33 AM, Tom Tromey wrote:
> Since then I have been wondering why we need build infrastructure in
> common/ at all. It seems to me that it can cause problems, but
> conversely doesn't provide much benefit.
>
I assume the problems here are C macros confusion/conflict, mentioned in
http://sourceware.org/ml/gdb-patches/2011-02/msg00466.html
AFAICS, the conflict can not happen. When building libcommon, config.h
is used from parent directory (gdb or gdbserver). GDB_INCLUDE in
common/configure.ac makes sure correct directories are included.
The only problem I can see is this:
#ifdef GDBSERVER
#include "server.h"
#else
#include "defs.h"
#include "gdb_string.h"
#endif
#ifndef GDBSERVER
enum target_signal
target_signal_from_command (int num)
...
#endif
However, IMO, it is not a configure/make problem. The real problem here
is we include some gdb-specific code in common. We can fix this problem
by moving gdb-specific part to gdb/ dir. Patch attached is for this
purpose.
> My reasoning is based on the fact that we are going to be building two
> libraries for the foreseeable future. It seems to me that it would be
> simpler to just integrate the common/ build rules into
> gdbserver/Makefile.in and gdb/Makefile.in.
>
> What do you think of that? I may write a patch to do it.
The goal of this piece of work is to remove duplicated source code, and
merge them together. However, the complexity of configure/make is
underestimated. I am not objecting to Tom's approach, because it is simple.
Personally, I still prefer a separated configure/makefile in common/,
because,
1. if my patch works, configure/make is not a problem,
2. if we look forward, there should be quite a few *.c and *.h files in
common in the future. Write rules in both gdb/Makefile.in and
gdbserver/Makefile.in doesn't scale.
I am sorry if this change makes some troubles, but it is a right
direction we have to go. In short, please review my approach again, and
I am not objecting to Tom's approach.
--
Yao (é½å°§)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gdb-specific-signals-0224.patch
Type: text/x-patch
Size: 5892 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20110224/9478498b/attachment.bin>
More information about the Gdb-patches
mailing list