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

Kevin Buettner wrote:
> 
> 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.)

OK, I'm not entirely clear why the LWP is 1, but it's clear
that this warning is spurious.  It's happening because I made
resume send the inferior_ptid to target_resume whenever stepping
over a breakpoint, regardless of whether the program is 
multi-threaded or not.  Probably we cannot expect to have a
valid LWP at that point.

I will silence the warning.

Michael