This is the mail archive of the
mailing list for the GDB project.
Re: wrong assumptions about pthread_t being numeric
On Sat, Oct 1, 2011 at 11:00 AM, Mark Kettenis <firstname.lastname@example.org> wrote:
>> From: Pedro Alves <email@example.com>
>> Date: Sat, 1 Oct 2011 02:59:59 +0100
>> > there
>> > should be at least a explicit function/macro which takes a thread_t and
>> > converts it to long, since it is assumed in a couple of spots that it is
>> > of this type.
>> > that is exactly what my patch does.
>> > and as you wished, it fixes the current issue with minimal effort.
>> The patch has a number of problems (no biggie, just the usual for
>> someone not used to GNU code). ?I'll take a look if I still failed
>> to convince you to change musl instead.
> No, I think you shouldn't. ?This whole madness with a zillion Linux
> libc's has to stop. ?We can't add support for each and every one of
> them. ?I think we should take the position that if people want thread
> support for their non-standard libc's in GDB they should provide a
> libthread_db.so that is ABI compatible with the one provided by glibc.
> Since pthread_t is part of that ABI, that means pthread_t has to be
> "unsigned long int".
Just my 2 cents here,
but a few years ago, I developped a library named "User-Level
Thread_db" , which aims at reducing the burden of thread-library
developpers when it comes to provide debuggers support.
> they should provide a libthread_db.so that is ABI compatible with the one provided by glibc
I took the opposite approach: I developped the `libthread_db.so' and
the thread-target on GDB's side, and then specified a very light API
to link `libthread_db.so' to the threading library.
The appoach was demonstrated efficient on two different libraries,
just a few days requied for the integration.
That was on the 6.8 days, so some adaptations should be necessary for
7.*, but most of the work is already in place.