When is a tid a lwp and vice versa?

When is a tid a lwp and vice versa?

[John Hughes]

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?

-- 
John Hughes <john@Calva.COM>
 

RE: When is a tid a lwp and vice versa?

[John Hughes]

So, say I have a process with one lwp, i.e. no threads: 
what should I have in procinfo_list?  One entry for the
process, with tid=0, or two entries, one with tid=0 and
the other with tid=1?

What if I have two lwp's, how many procinfo entries?
Two or three?

Any clues?

I can hack things so I get no warnings and things work
by doing this:

--- procfs.c.orig       Thu Jun 28 15:35:28 2001
+++ procfs.c    Fri Jun 29 12:27:55 2001
@@ -4907,6 +4907,9 @@
      the actual process ID plus the lwp ID. */
   inferior_ptid = MERGEPID (pi->pid, proc_get_current_thread (pi));
 
+  /* Is this too horrid?  open all the lwp's of the new kiddy */
+  procfs_find_new_threads ();
+
 #ifdef START_INFERIOR_TRAPS_EXPECTED
   startup_inferior (START_INFERIOR_TRAPS_EXPECTED);
 #else

RE: When is a tid a lwp and vice versa?

[John Hughes]

>>
>> 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.)

The first lwpid is 1, like the first pid is 1.

$  ps -fLp 1,$$
     UID   PID  PPID   LWP  NLWP  CLS PRI  C    STIME TTY     LTIME COMD
    root     1     0     1     1   TS  70  0   Jun 25 ?        5:26
/sbin/init
    john  1576  1574     1     1   TS  70  0   Jul 06 pts/19   0:00 -bash

Re: When is a tid a lwp and vice versa?

[Michael Snyder]

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

Re: When is a tid a lwp and vice versa?

[Kevin Buettner]

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

RE: When is a tid a lwp and vice versa?

[John Hughes]

> 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.

Yeah, my fault, I misunderstood what was going on.

> 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...

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.

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.