public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug threads/17254] New: ptid.tid cleanup
@ 2014-08-11  0:49 xdje42 at gmail dot com
  0 siblings, 0 replies; only message in thread
From: xdje42 at gmail dot com @ 2014-08-11  0:49 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=17254

            Bug ID: 17254
           Summary: ptid.tid cleanup
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: threads
          Assignee: unassigned at sourceware dot org
          Reporter: xdje42 at gmail dot com

Filing this for reference sake.
Use of lwp and tid in ptid is confusing.

ptid.h has this:

struct ptid
{
  /* Process id.  */
  int pid;

  /* Lightweight process id.  */
  long lwp;

  /* Thread id.  */
  long tid;
};

In a linux 32-cross-64 situation pthread_t will be 64 bits.
But as it turns out, pthread_t isn't stored in ptid anyway.
E.g., thread_db_pid_to_str fetches tid from a private structure and not ptid.

static char *
thread_db_pid_to_str (struct target_ops *ops, ptid_t ptid)
{
  struct thread_info *thread_info = find_thread_ptid (ptid);
  struct target_ops *beneath;

  if (thread_info != NULL && thread_info->private != NULL)
    {
      static char buf[64];
      thread_t tid;

      tid = thread_info->private->tid;
      snprintf (buf, sizeof (buf), "Thread 0x%lx (LWP %ld)",
                tid, ptid_get_lwp (ptid));

      return buf;
    }

  beneath = find_target_beneath (ops);
  return beneath->to_pid_to_str (beneath, ptid);
}

linux-thread-db.c explains it thusly:

   Process IDs managed by linux-thread-db.c match those used by                 
   linux-nat.c: a common PID for all processes, an LWP ID for each              
   thread, and no TID.  We save the TID in private.  Keeping it out             
   of the ptid_t prevents thread IDs changing when libpthread is                
   loaded or unloaded.

It's not obvious why storing tid separately is the only (reasonable) solution.
More documentation would be helpful.

ptid.h has this:

   process_stratum targets that handle threading themselves should              
   prefer using the ptid.lwp field, leaving the ptid.tid field for any          
   thread_stratum target that might want to sit on top.

It would be good to mention use of tid is still optional,
but I wonder if we can do better.

Another example:
gdbserver/lynx-low.c stores tid in lwp:

/* Build a ptid_t given a PID and a LynxOS TID.  */

static ptid_t
lynx_ptid_build (int pid, long tid)
{
  /* brobecker/2010-06-21: It looks like the LWP field in ptids                 
     should be distinct for each thread (see write_ptid where it                
     writes the thread ID from the LWP).  So instead of storing                 
     the LynxOS tid in the tid field of the ptid, we store it in                
     the lwp field.  */
  return ptid_build (pid, tid, 0);
}

I realize the acronyms "lwp" and "tid" needn't straightforwardly transfer from
system to system, but I wonder if gdb can do better.

Another example:
windows-nat.c stores the lwp in tid for ada tasks

static ptid_t
windows_get_ada_task_ptid (struct target_ops *self, long lwp, long thread)
{
  return ptid_build (ptid_get_pid (inferior_ptid), 0, lwp);
}

I didn't do an exhaustive search for examples.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2014-08-11  0:49 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-08-11  0:49 [Bug threads/17254] New: ptid.tid cleanup xdje42 at gmail dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).