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

[Pedro Alves <pedro@codesourcery.com>]

On Friday 23 April 2010 16:36:01, Mark Kettenis wrote:
> > From: Pedro Alves <pedro@codesourcery.com>

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

Maybe.  That's a fair point.  I've no sensibility whether TID would
be more or less confusing for linux users.

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

Completely decoupling would mean no default at all ;-)

I'll eventually come up with a patch, though not this
week, probably.

-- 
Pedro Alves