This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: wrong assumptions about pthread_t being numeric
- From: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- To: pedro at codesourcery dot com
- Cc: maillist-gdbpatches at barfooze dot de, gdb-patches at sourceware dot org
- Date: Sat, 1 Oct 2011 11:00:19 +0200 (CEST)
- Subject: Re: wrong assumptions about pthread_t being numeric
- References: <4E73D06F.603@barfooze.de> <201109171629.09383.pedro@codesourcery.com> <4E8665ED.4070905@barfooze.de> <201110010300.00160.pedro@codesourcery.com>
> From: Pedro Alves <pedro@codesourcery.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".