[PATCH] Add pthread_getname_np, pthread_setname_np

[Yaakov (Cygwin/X)]

This patchset adds pthread_getname_np and pthread_setname_np.  These
were added to glibc in 2.12[1] and are also present in some form on
NetBSD and several UNIXes.  IIUC recent versions of GDB can benefit from
this support.

The code is based on NetBSD's implementation with changes to better
match Linux behaviour.  It does differ from Linux in two points:

* The thread name is not affected by changing __progname (or
program_invocation_short_name on Linux).  I used the latter because it
is cheaper than the pinfo->progname dance (e.g. in
format_process_stat()).

* pthread_setname_np(thr, NULL) segfaults on Linux (and NetBSD), but our
snprintf is apparently more robust and treats it as an empty string.

I'll leave it up to you to decide if either of these matter.

I implemented this via class pthread_attr to make it easier to add
pthread_attr_[gs]etname_np (present in NetBSD and some UNIXes) should it
ever be added to Linux (or we decide we want it anyway).

Patches and test code attached.


Yaakov

[1] http://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS

[Corinna Vinschen-2]

On Feb 23 21:38, Yaakov (Cygwin/X) wrote:
> This patchset adds pthread_getname_np and pthread_setname_np.  These
> were added to glibc in 2.12[1] and are also present in some form on
> NetBSD and several UNIXes.  IIUC recent versions of GDB can benefit from
> this support.

Thanks for your patch, but I don't think it's the whole thing.

Consider, if you implement pthread_[gs]etname_np as you did, then you
have pthread names which are only available to the process in which
the threads are running.  So, how could GDB get the information for
its inferior process?

Actually GDB reads the thread name using a target specific function
which is so far only implemented for Linux.  It does not use
pthread_getname_np, rather it reads the name from /proc/$PID/task/$TID/comm.

And that's a bit of a problem in Cygwin.  Every Cygwin process is
multi-threaded (think signals), but only the application-started threads
are pthreads.

So, again, thanks for doing this, but I think this requires more work to
be useful.  The basic task is to provide /proc/$PID/task for all threads
running in a Cygwin process.  If that's available, the pthread_[gs]etname_np
will become useful and their (different) implementation probably falls into
place.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

[Yaakov (Cygwin/X)]

On Fri, 2012-02-24 at 10:38 +0100, Corinna Vinschen wrote:

> On Feb 23 21:38, Yaakov (Cygwin/X) wrote:
> > This patchset adds pthread_getname_np and pthread_setname_np.  These
> > were added to glibc in 2.12[1] and are also present in some form on
> > NetBSD and several UNIXes.  IIUC recent versions of GDB can benefit from
> > this support.
>
> Thanks for your patch, but I don't think it's the whole thing.
>
> Consider, if you implement pthread_[gs]etname_np as you did, then you
> have pthread names which are only available to the process in which
> the threads are running.

My implementation is based on NetBSD's[1].  So what purpose do these
functions serve then on that it and the UNIXes?  (Serious question.)


Yaakov

[1] http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libpthread/pthread.c?rev=1.125

[Corinna Vinschen-2]

On Feb 24 05:00, Yaakov (Cygwin/X) wrote:

> On Fri, 2012-02-24 at 10:38 +0100, Corinna Vinschen wrote:
> > On Feb 23 21:38, Yaakov (Cygwin/X) wrote:
> > > This patchset adds pthread_getname_np and pthread_setname_np.  These
> > > were added to glibc in 2.12[1] and are also present in some form on
> > > NetBSD and several UNIXes.  IIUC recent versions of GDB can benefit from
> > > this support.
> >
> > Thanks for your patch, but I don't think it's the whole thing.
> >
> > Consider, if you implement pthread_[gs]etname_np as you did, then you
> > have pthread names which are only available to the process in which
> > the threads are running.
>
> My implementation is based on NetBSD's[1].  So what purpose do these
> functions serve then on that it and the UNIXes?  (Serious question.)

See the source of the pthread_setname_np function.  There's a call to
the kernel:

  thread->pt_name = cp;
  (void)_lwp_setname(thread->pt_lid, cp);

_lwp_setname ultimately calls the kernel function sys__lwp_setname in
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/sys_lwp.c?rev=1.53
So the kernel knows the name and the sys__lwp_getname entry point
can be used to fetch the name of a thread in another process.  How
exactly this is fetched by which BSD tool, I don't know, but it's
all in the sources :)


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

[Pedro Alves-7]

Just FYI,

Windows' way to have the program affect thread names in the
debugger is with SetThreadName, which throws a magic exception
which the debugger can catch.  GDB doesn't know about this though.

 http://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx

Just for completeness...  I don't know if there's a native
method that's closer to pthread_setname_np's semantics.

--
Pedro Alves