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

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

[Carlo Wood]

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

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

[Jim Blandy]

Carlo Wood <carlo@alinoe.com> writes:
> Sent originally to the wrong list.
> Note I am not subbed to gdb@sources.redhat.com.

Thanks!

Unfortunately, this still isn't really enough information.  Think of
it this way: in order for us to fix a bug, we need step-by-step
instructions which allow us to reproduce the bug ourselves, on our own
machine.

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

[Carlo Wood]

On Tue, Jul 03, 2001 at 01:15:15PM -0500, Jim Blandy wrote:
> Carlo Wood <carlo@alinoe.com> writes:
> > Sent originally to the wrong list.
> > Note I am not subbed to gdb@sources.redhat.com.
> 
> Thanks!
> 
> Unfortunately, this still isn't really enough information.  Think of
> it this way: in order for us to fix a bug, we need step-by-step
> instructions which allow us to reproduce the bug ourselves, on our own
> machine.

It wasn't meant to be :).  I already sent this before you requested
more info.  I'll try to fix up some test cases when I run into these
problems next time.

-- 
Carlo Wood <carlo@alinoe.com>