Re: wrong assumptions about pthread_t being numeric

[Pedro Alves <pedro@codesourcery.com>]

On Saturday 01 October 2011 01:59:25, John Spencer wrote:
> >>> i disagree. adding a proper solution once is superior to creating dozens
> >>> of special case hacks.
> >> What's the "proper" solution then?  The only possible way I can think
> >> of to handle some libc what uses a struct for pthread_t, is with some way at
> >> runtime to know which libc/thread_db gdb is talking to, failing that,
> >> #ifdefs and/or autoconfig'ury.  Since a simple cast will
> >> work for glibc, android, musl, and whatever other libc's happen be
> >> be building gdbserver today, what's the point?
> > I'll even go a step further, and suggest you do expose pthread_t
> > as a typedef to long in public headers, and cast it to pointer internally
> > in musl, just like glibc and most other libc's do.  Hiding the fact
> > that you implement things with a pointer could even be a good thing.
> >
> > It's just easier for everybody else that way.  There's really no point in
> > being different for the sake of it.
> >
> 
> that's definitely going to far, you can't dictate how libcs should 
> handle an opaque type internally just to keep broken code working.

The fact that you're still calling gdb's libthread_db.so handling
code broken because of this only shows that you still missed the point
of the code you're talking about.  Let me sum it up:
The debugger is coordinating with a libc-provided shared library, that
is used to peek at the libc's internal state.  pthread_t's type is
implementation defined.  The debugger's code in question is interacting
with a specific libc implementation (glibc).  For that fact, the
debugger's code in question can be seen as being part of "the
implementation" (as in the pthread_t's type being implementation
defined part).  The fact that other libcs work with the same code
is a bonus.

Again:

> that's definitely going to far, you can't dictate how libcs should 
> handle an opaque type internally just to keep broken code working.

I can at least try to persuade one libc author into sanity.  :-)

Ever heard of not inflicting unnecessary pain on others for no
good reason?   You know people do sprinkle around printfs of
pthread_t's for debug purposes, don't you?  Things like printing
printf ("%ld been here\n", pthread_self ()).  I really don't see
the point of not being source compatible with glibc (and all other
linux libcs) when it's super easy to be so...

Again:

> that's definitely going to far, you can't dictate how libcs should 
> handle an opaque type internally just to keep broken code working.

public header:

typedef unsigned long pthread_t;

musl implementation:

struct pthread
{
  whatever you have today;
};

int pthread_foo_public_function (pthread_t th, ...)
{
   struct pthread *t = (pthread_t) th;
  
   // business as usual.
}

There, how did that dictate how your libc handles its
opaque type _internally_ again?  It shouldn't take more than
15 minutes to change all of that in musl, and everyone lives
happy ever after.

> 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.

-- 
Pedro Alves