Re: pthread_t ids of threads not showed by "thread info"

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> From: Pedro Alves <pedro@codesourcery.com>
> Date: Fri, 23 Apr 2010 13:47:31 +0100
> 
> On Friday 23 April 2010 13:29:52, Mark Kettenis wrote:
> > If you ask me, whoever made the change from process to thread (cvs
> > annotate says it's you ;), made a mistake.  
> 
> Yep.  No need to ask, I already said so.  ;-)
> 
> > The interpretation of the
> > pid read from the core file really is OS-specific.  The default
> > core_pid_to_str should really be the lowest common denominator, i.e,
> > normal_pid_to_str().  That's really the only thing that makes sense
> > for non-threaded code on a UNIX-like system.  
> 
> Yeah, probably.  What are the targets we support you're thinking
> where "process" would make more sense and be less confusing
> than "LWP"?  Pedantic-ness issues aside, seeing multiple
> "processes" in the list when all the processes share a single
> address space looks a bit strange to me.

I was thinking of *any* target running a UNIX-like OS.  For for the
(typical) user debugging a non-threaded program on a UNIX-like OS,
seeing "Thread ..." or "LWP ..." is confusing.  Especially the term
"LWP" will be pretty cryptic to many people not familliar with
implementation details of the Solaris/SVR4.2 MP/NetBSD threads
implementations.

One can even argue that it's the wrong thing to use on Linux.  I don't
think the Linux kernel has the concept of an LWP.  A more appropriate
term on Linux would be TID, at least that is what the gettid() man
page uses and what's used in the comments in the kernel sources.

> > The threads stratum then
> > can override this for threaded code.
> > 
> > If like on Linux, the threading stuff is messed up for core files, and
> > not easily fixable, it is probably more helpful to print LWP's like
> > you suggest.  
> 
> It's not about that, that's a different issue.  In linux, assume
> we're talking about the core of a program that didn't use any
> pthreads facilities (used raw `clone'), and you still have
> multiple processes listed in the core.

Right.  It would be nice if that produced meaningful output as well.

> > But in my opinion that really should be done by
> > overriding the default using set_gdbarch_core_pid_to_str().
> 
> That works, of course.  I'm just thinking of the practical
> aspect.  If we have many targets that want "LWP", and one
> that wants "process", is it worth the hassle?

I think decoupling things will help us here in the long run.