From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carlo Wood To: gdb@sources.redhat.com Subject: [carlo@alinoe.com: Re: RFC c++ debugging thread] Date: Mon, 02 Jul 2001 20:37:00 -0000 Message-id: <20010703053732.A10938@alinoe.com> X-SW-Source: 2001-07/msg00008.html Sent originally to the wrong list. Note I am not subbed to gdb@sources.redhat.com. -- Carlo Wood >From kevinb@cygnus.com Tue Jul 03 10:52:00 2001 From: Kevin Buettner To: "John Hughes" , 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: 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