This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: pthread_t ids of threads not showed by "thread info"
> 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.