[patch] Remove HAVE_UINTPTR_T from gdb_thread_db.h

[patch] Remove HAVE_UINTPTR_T from gdb_thread_db.h

[Yao Qi]

[-- Attachment #1: Type: text/plain, Size: 555 bytes --]

When I am trying to move gdb_thread_db.h to common/ dir, 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 (齐尧)

[-- Attachment #2: remove_HAVE_UINTPTR_T.patch --]
[-- Type: text/x-patch, Size: 759 bytes --]

2011-05-14  Yao Qi  <yao@codesourcery.com>

	* gdb/gdb_thread_db.h: Remove HAVE_UINTPTR_T.

diff --git a/gdb/gdb_thread_db.h b/gdb/gdb_thread_db.h
index e20b415..c770b0c 100644
--- a/gdb/gdb_thread_db.h
+++ b/gdb/gdb_thread_db.h
@@ -203,16 +203,6 @@ typedef struct td_notify
   } u;
 } td_notify_t;
 
-/* Some people still have libc5 or old glibc with no uintptr_t.
-   They lose.  glibc 2.1.3 was released on 2000-02-25, and it has
-   uintptr_t, so it's reasonable to force these people to upgrade.  */
-
-#ifndef HAVE_UINTPTR_T
-#error No uintptr_t available; your C library is too old.
-/* Inhibit further compilation errors after this error.  */
-#define uintptr_t void *
-#endif
-
 /* Structure used to report event.  */
 typedef struct td_event_msg
 {

Re: [patch] Remove HAVE_UINTPTR_T from gdb_thread_db.h

[Joel Brobecker]

> 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

Re: [patch] Remove HAVE_UINTPTR_T from gdb_thread_db.h

[Yao Qi]

On 05/15/2011 01:07 AM, Joel Brobecker wrote:
>> 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 wrote up plan in wiki http://sourceware.org/gdb/wiki/Common .  I am
not good at naming a project, so I name it as "Common" temporally.

The plan is not done.  I will complete it, and fill in with more details.

Comments are welcome, and thanks in advance to put up with my writing.

-- 
Yao (齐尧)

[committed] [patch] Remove HAVE_UINTPTR_T from gdb_thread_db.h

[Yao Qi]

On 05/15/2011 01:07 AM, Joel Brobecker wrote:
>> > 2011-05-14  Yao Qi  <yao@codesourcery.com>
>> > 
>> > 	* gdb/gdb_thread_db.h: Remove HAVE_UINTPTR_T.
> This is OK.

Committed.  http://sourceware.org/ml/gdb-cvs/2011-05/msg00209.html

-- 
Yao (齐尧)

Re: [patch] Remove HAVE_UINTPTR_T from gdb_thread_db.h

[Thiago Jung Bauermann]

On Mon, 2011-05-16 at 13:40 +0800, Yao Qi wrote:
> On 05/15/2011 01:07 AM, Joel Brobecker wrote:
> >> 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 wrote up plan in wiki http://sourceware.org/gdb/wiki/Common .  I am
> not good at naming a project, so I name it as "Common" temporally.
> 
> The plan is not done.  I will complete it, and fill in with more details.
> 
> Comments are welcome, and thanks in advance to put up with my writing.

I'm not familiar with gdbserver but would it make sense to make
gdbserver internally use the target_ops vector? That would make GDB's
-nat.c files usable without modification in gdbserver. Then it would be
a matter of porting the gdbserver's additional features which GDB native
doesn't have.
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center

Re: [patch] Remove HAVE_UINTPTR_T from gdb_thread_db.h

[Tom Tromey]

>>>>> "Thiago" == Thiago Jung Bauermann <bauerman@br.ibm.com> writes:

Thiago> I'm not familiar with gdbserver but would it make sense to make
Thiago> gdbserver internally use the target_ops vector? That would make GDB's
Thiago> -nat.c files usable without modification in gdbserver. Then it would be
Thiago> a matter of porting the gdbserver's additional features which GDB native
Thiago> doesn't have.

The idea makes sense; I think it is among those discussed in previous
threads on this topic.

The devil is in the details.  The *-nat.c files are free to use any
other facility provided by gdb.  So, perhaps this approach would bloat
gdbserver excessively.

At least, I believe that is the standard objection.  I have not
investigated the problem myself.  My view is somewhat more meta: I think
merging the two makes sense, just to avoid the "double patch" problem,
and an important quality is the maintainability of the result; but the
exact path to get there I think it up to whoever does the work.

On this basis, I think Yao's approach, as communicated on the wiki,
seems reasonable.

Tom

Re: [patch] Remove HAVE_UINTPTR_T from gdb_thread_db.h

[Joel Brobecker]

> Thiago> I'm not familiar with gdbserver but would it make sense to make
> Thiago> gdbserver internally use the target_ops vector? That would make GDB's
> Thiago> -nat.c files usable without modification in gdbserver. Then it would be
> Thiago> a matter of porting the gdbserver's additional features which GDB native
> Thiago> doesn't have.
> 
> The idea makes sense; I think it is among those discussed in previous
> threads on this topic.
> 
> The devil is in the details.  The *-nat.c files are free to use any
> other facility provided by gdb.  So, perhaps this approach would bloat
> gdbserver excessively.

I think that the target_ops vector does a lot more than what gdbserver
needs to do. So they way I have been thinking about it, in conceptual
terms, is to incorporate the gdbserver's target vector into GDB's
target vector.  In practice, it's probably going to be something
different, but I see the future as gdbserver being a module inside
GDB. and the GDBserver executable can be that module with the extra
remore-protocol implementation on top of that.

-- 
Joel