[carlo@alinoe.com: Re: RFC c++ debugging thread]

[Carlo Wood <carlo@alinoe.com>]

Sent originally to the wrong list.
Note I am not subbed to gdb@sources.redhat.com.

-- 
Carlo Wood <carlo@alinoe.com>
From kevinb@cygnus.com Tue Jul 03 10:52:00 2001
From: Kevin Buettner <kevinb@cygnus.com>
To: "John Hughes" <john@Calva.COM>, <gdb@sourceware.cygnus.com>
Subject: Re: When is a tid a lwp and vice versa?
Date: Tue, 03 Jul 2001 10:52:00 -0000
Message-id: <1010703175044.ZM25944@ocotillo.lan>
References: <CDENKKMHIFMALMCCKPCFIEEFCAAA.john@Calva.COM> <john@Calva.COM>
X-SW-Source: 2001-07/msg00009.html
Content-length: 1100

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