From mboxrd@z Thu Jan  1 00:00:00 1970
From: Kevin Buettner <kevinb@cygnus.com>
To: "John Hughes" <john@Calva.COM>, <gdb@sourceware.cygnus.com>
Cc: Michael Snyder <msnyder@cygnus.com>
Subject: Re: When is a tid a lwp and vice versa?
Date: Fri, 06 Jul 2001 08:50:00 -0000
Message-id: <1010706155030.ZM32038@ocotillo.lan>
References: <CDENKKMHIFMALMCCKPCFAEEMCAAA.john@Calva.COM> <john@Calva.COM>
X-SW-Source: 2001-07/msg00050.html

On Jul 4, 10:53am, John Hughes wrote:

> > 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.
> 
> Ok, here we go...

Thanks...

> In procfs_init_inferior we have:
> 
>   if ((pi = create_procinfo (pid, 0)) == NULL)
>     perror ("procfs: out of memory in 'init_inferior'");
> 
> so we make a procinfo with pid = pid and tid = 0
> 
> but later on we say:
> 
>   /* The 'process ID' we return to GDB is composed of
>      the actual process ID plus the lwp ID. */
>   inferior_ptid = MERGEPID (pi->pid, proc_get_current_thread (pi));
> 
> and proc_get_current_thread has:
> 
>   if (!pi->status_valid)
>     if (!proc_get_status (pi))
>       return 0;
>   return pi->prstatus.pr_lwp.pr_lwpid;
> 
> The lwpid is 1, not zero, of course.

Is 1 a reasonable value for pi->prstatus.pr_lwp.pr_lwpid ?  (It looks
rather fishy to me.)

> so the "lwp" field in inferior_ptid is now 1.  (tid is zero).
> 
> eventualy we call procfs_resume with inferior_ptid and then we do:
> 
>      if (PIDGET (ptid) != -1)
>        {
>          /* Resume a specific thread, presumably suppressing the others. */
>          thread = find_procinfo (PIDGET (ptid), TIDGET (ptid));
>          if (thread == NULL)
>            warning ("procfs: resume can't find thread %ld -- resuming all.",
>                     TIDGET (ptid));
> 
> Which prints the ugly message.

I seem to recall Michael Snyder saying something about this recently...
Something along the lines that his recent infrun.c fixes cause
spurious warnings in procfs.c.  I'm not sure if this was one of them
though...   (CC'd to Michael for his comment.)

Kevin