On 03/02/2011 08:14 PM, Joel Brobecker wrote:
> 
> This part, however, makes me uncomfortable.  There are a couple
> of reasons.  The current code is:
> 
>     if test x"$enable_gdbserver" = xyes; then
>       GDB_FLAGS="-DGDBSERVER"
>       GDB_INCLUDE="-I\$(srcdir)/../gdbserver/"
>     else
>       GDB_FLAGS=""
>       GDB_INCLUDE="-I\$(srcdir)/../ -I\$(BFD_DIR)"
>     fi
> 
> The first question is: I don't understand why we have different
> include and compilation flags. I can see how -DGDBSERVER is used
> to select between gdb's "defs.h" and gdbserver's "server.h". So,
> OK for now.  But for the rest, why do we maintain different include
> paths depending on whether we build it for GDB or for GDBserver?
> It's like a circular dependency.  I can explain that we need to
> select either $(srcdir)/../gdbserver/ or $(srcdir)/../ for the
> same reason as above (including "defs.h" or "server.h"). 

To your first question, because common/signals.c uses "ifdef GDBSERVER",
which makes a lot troubles here.  I think of this problem again, and
find that root cause of this problem is that files in common dir
includes some gdb-specific or gdbserver specific code.

If we move gdb-specific part of common/signals.c out of it, the include
and compilation flags can be unique.

This patch is to move gdb-specific code out of common/signals.c.
http://sourceware.org/ml/gdb-patches/2011-02/msg00669.html

Once this patch above is applied, we can remove these conditional
includes and flags setting code.

> For the rest, I think that the -I flags should be the same regardless
> of who we build these files for. In my mind, it's supposed to be
> actually independent from both GDB and GDBserver. And unfortunately,
> right now, it is dependent on both :-(.
> 

Yes, we should keep libcommon.a compilation flags the same.  As I said
above, we can make it independent via moving some of codes out of signals.c.

-- 
Yao (齐尧)