[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