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