Re: [patch] Remove HAVE_UINTPTR_T from gdb_thread_db.h

[Joel Brobecker <brobecker at adacore dot com>]

> When I am trying to move gdb_thread_db.h to common/ dir,

I am so sorry for not having the time to work on this project,
and so it make me uncomfortable saying this without offering
advice, but I still feel uncomfortable about not having a clear
plan, and not knowing where we are going with this. I'm afraid
that the end result might be a tighter inter-dependency between
GDB and GDBserver instead of GDB and GDBserver sitting on top
of a common API (we could call it a mini libgdb).

I guess what I'm trying to say is that I'd like to see a plan to
move functionality, rather than just some definitions that we happen
to be using from both ends.



I find there is
> still a macro check like,
> 
> #ifndef HAVE_UINTPTR_T
> ...
> #endif
> 
> I don't think we need this any more.  This piece of code was introduced
> by patch [1] in 2003, however, in 2008, Daniel has a patch [2] to remove
> tests for uintptr_t.
> 
> OK to remove this check?
> 
> [1] [rfa] gdb_thread_db.h: #errror if no uintptr_t.
> http://sourceware.org/ml/gdb-patches/2003-02/msg00708.html
> [2] [RFC] Use gnulib's stdint.h.
> http://sourceware.org/ml/gdb-patches/2008-06/msg00478.html
> 
> -- 
> Yao (??????)

> 2011-05-14  Yao Qi  <yao@codesourcery.com>
> 
> 	* gdb/gdb_thread_db.h: Remove HAVE_UINTPTR_T.

This is OK.

Your change, though, is made possible only because GDB uses gnulib.
This is not the case for GDBserver, which might become a problem
if we think we should support it on older libc's.

That being said, I'm again quite uncomfortable not knowing what is
going to be moved to common and how. I am so sad that I do not have
the time right now to help with planning this, not being able to
provide suggestions at this time.  But what I'm seeing is some stuff
being moved to common/ pretty much on demand without much of a design.
I'm afraid that, if we're not careful, we'll end up with a tighter
interdependency between GDB and GDBserver.  What I'd like to see
is functionality being moved to common, and accessible through
an API, a mini libgdb if you will, not just linux-only definitions.

(it's interesting that I'm leaning towards the idea of making common/
a sub-project of GDB/GDBserver, with Makefile and all, the way it was
initially implemented)

-- 
Joel