This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: When is a tid a lwp and vice versa?
- To: "John Hughes" <john at Calva dot COM>, <gdb at sourceware dot cygnus dot com>
- Subject: Re: When is a tid a lwp and vice versa?
- From: Kevin Buettner <kevinb at cygnus dot com>
- Date: Tue, 3 Jul 2001 10:50:44 -0700
- References: <CDENKKMHIFMALMCCKPCFIEEFCAAA.john@Calva.COM>
On Jun 29, 10:52am, John Hughes wrote:
> I'm playing with the 20010627 snapshot on a UnixWare system.
> Work's ok but when debugging non-threaded programs I get lots
> of "warning: procfs: resume can't find thread 1 -- resuming all."
> messages.
>
> This is 'cos the single entry in procinfo_list has pi->tid set
> to 0, but procfs_resume is calling find_procinfo with
> TIDGET(inferior_ptid), which returns the lwpid, which is 1
> not zero.
>
> Any ideas?
For UnixWare, it is important to understand that the ``tid'' member of
a ptid_t is used as a flag to indicate whether or not the composite
id represents a user-space thread id or an lwp id. (1 for the former;
0 for the latter.)
When I first read your message, it seemed to me that perhaps some code
somewhere was getting these confused. I've looked over
config/i386/tm-i386v42mp.h but don't see a problem though.
Anyway... it would be a tremendous help if you could figure out why
(and how) the lwp component of inferior_ptid is getting set to 1.
Also, it would be useful to know what the tid value is in this
circumstance.
Kevin