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

[Pedro Alves <pedro at codesourcery dot com>]

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.

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

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

-- 
Pedro Alves