From mboxrd@z Thu Jan  1 00:00:00 1970
From: "John Hughes" <john@Calva.COM>
To: "Kevin Buettner" <kevinb@cygnus.com>, <gdb@sourceware.cygnus.com>
Subject: RE: When is a tid a lwp and vice versa?
Date: Wed, 04 Jul 2001 01:54:00 -0000
Message-id: <CDENKKMHIFMALMCCKPCFAEEMCAAA.john@Calva.COM>
References: <1010703175044.ZM25944@ocotillo.lan>
X-SW-Source: 2001-07/msg00020.html

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