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