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