public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
* [PATCH 0/2] remote.c: ptid.tid -> ptid.lwp
@ 2014-02-12 14:07 Pedro Alves
  2014-02-12 14:07 ` [PATCH 1/2] remote.c: Use the ptid.lwp field to store remote thread ids rather than ptid.tid Pedro Alves
                   ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: Pedro Alves @ 2014-02-12 14:07 UTC (permalink / raw)
  To: gdb-patches

See patch #1 for details.

I plan to push this in soon, assuming no barring comments.

Pedro Alves (2):
  remote.c: Use the ptid.lwp field to store remote thread ids rather
    than ptid.tid.
  common/ptid.h: Mention that process_stratum targets should prefer
    ptid.lwp.

 gdb/common/ptid.h |  7 ++++++-
 gdb/remote.c      | 34 +++++++++++++++++-----------------
 2 files changed, 23 insertions(+), 18 deletions(-)

-- 
1.7.11.7

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [PATCH 1/2] remote.c: Use the ptid.lwp field to store remote thread ids rather than ptid.tid.
  2014-02-12 14:07 [PATCH 0/2] remote.c: ptid.tid -> ptid.lwp Pedro Alves
@ 2014-02-12 14:07 ` Pedro Alves
  2014-02-12 16:56   ` Tom Tromey
  2014-02-12 18:09   ` Doug Evans
  2014-02-12 14:07 ` [PATCH 2/2] common/ptid.h: Mention that process_stratum targets should prefer ptid.lwp Pedro Alves
  2014-02-19 19:09 ` [PATCH 0/2] remote.c: ptid.tid -> ptid.lwp Pedro Alves
  2 siblings, 2 replies; 7+ messages in thread
From: Pedro Alves @ 2014-02-12 14:07 UTC (permalink / raw)
  To: gdb-patches

From GDB's perspective, independently of how the target really
implements threads, gdb/remote sees all threads as if kernel/system
threads.  A rationale along theses lines led to gdbserver storing
thread ids in ptid.lwp in all ports.

I believe that on the GDB side too, it's best that we standardize on
process_stratum targets using the ptid.lwp field to store thread ids.
The idea being leave the ptid.tid field free for any thread_stratum
target that might want to sit on top.

Because remote.c is currently using ptid.tid, we can't make gdbserver
and gdb share bits of remote-specific code that manipulates ptids.

This patch thus makes remote.c use ptid.lwp instead of ptid.tid.

Tested on x86_64 Fedora 17, w/ local gdbserver.

gdb/
2014-02-12  Pedro Alves  <palves@redhat.com>

	* remote.c (remote_thread_alive, write_ptid, read_ptid)
	(read_ptid, remote_newthread_step, remote_threads_extra_info)
	(remote_get_ada_task_ptid, append_resumption, remote_stop_ns)
	(threadalive_test, remote_pid_to_str, _initialize_remote): Use the
	ptid.lwp field to store remote thread ids rather than ptid.tid.
---
 gdb/remote.c | 34 +++++++++++++++++-----------------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/gdb/remote.c b/gdb/remote.c
index eff4c44..02f2669 100644
--- a/gdb/remote.c
+++ b/gdb/remote.c
@@ -1877,7 +1877,7 @@ remote_thread_alive (struct target_ops *ops, ptid_t ptid)
     /* The main thread is always alive.  */
     return 1;
 
-  if (ptid_get_pid (ptid) != 0 && ptid_get_tid (ptid) == 0)
+  if (ptid_get_pid (ptid) != 0 && ptid_get_lwp (ptid) == 0)
     /* The main thread is always alive.  This can happen after a
        vAttach, if the remote side doesn't support
        multi-threading.  */
@@ -2021,7 +2021,7 @@ write_ptid (char *buf, const char *endbuf, ptid_t ptid)
       else
 	buf += xsnprintf (buf, endbuf - buf, "p%x.", pid);
     }
-  tid = ptid_get_tid (ptid);
+  tid = ptid_get_lwp (ptid);
   if (tid < 0)
     buf += xsnprintf (buf, endbuf - buf, "-%x", -tid);
   else
@@ -2051,7 +2051,7 @@ read_ptid (char *buf, char **obuf)
       pp = unpack_varlen_hex (p + 1, &tid);
       if (obuf)
 	*obuf = pp;
-      return ptid_build (pid, 0, tid);
+      return ptid_build (pid, tid, 0);
     }
 
   /* No multi-process.  Just a tid.  */
@@ -2068,7 +2068,7 @@ read_ptid (char *buf, char **obuf)
 
   if (obuf)
     *obuf = pp;
-  return ptid_build (pid, 0, tid);
+  return ptid_build (pid, tid, 0);
 }
 
 /* Encode 64 bits in 16 chars of hex.  */
@@ -2618,7 +2618,7 @@ static int
 remote_newthread_step (threadref *ref, void *context)
 {
   int pid = ptid_get_pid (inferior_ptid);
-  ptid_t ptid = ptid_build (pid, 0, threadref_to_int (ref));
+  ptid_t ptid = ptid_build (pid, threadref_to_int (ref), 0);
 
   if (!in_thread_list (ptid))
     add_thread (ptid);
@@ -2887,7 +2887,7 @@ remote_threads_extra_info (struct thread_info *tp)
 		    _("remote_threads_extra_info"));
 
   if (ptid_equal (tp->ptid, magic_null_ptid)
-      || (ptid_get_pid (tp->ptid) != 0 && ptid_get_tid (tp->ptid) == 0))
+      || (ptid_get_pid (tp->ptid) != 0 && ptid_get_lwp (tp->ptid) == 0))
     /* This is the main thread which was added by GDB.  The remote
        server doesn't know about it.  */
     return NULL;
@@ -2926,7 +2926,7 @@ remote_threads_extra_info (struct thread_info *tp)
   rs->use_threadextra_query = 0;
   set = TAG_THREADID | TAG_EXISTS | TAG_THREADNAME
     | TAG_MOREDISPLAY | TAG_DISPLAY;
-  int_to_threadref (&id, ptid_get_tid (tp->ptid));
+  int_to_threadref (&id, ptid_get_lwp (tp->ptid));
   if (remote_get_threadinfo (&id, set, &threadinfo))
     if (threadinfo.active)
       {
@@ -3035,7 +3035,7 @@ remote_static_tracepoint_markers_by_strid (const char *strid)
 static ptid_t
 remote_get_ada_task_ptid (long lwp, long thread)
 {
-  return ptid_build (ptid_get_pid (inferior_ptid), 0, lwp);
+  return ptid_build (ptid_get_pid (inferior_ptid), lwp, 0);
 }
 \f
 
@@ -4847,7 +4847,7 @@ append_resumption (char *p, char *endp,
       ptid_t nptid;
 
       /* All (-1) threads of process.  */
-      nptid = ptid_build (ptid_get_pid (ptid), 0, -1);
+      nptid = ptid_build (ptid_get_pid (ptid), -1, 0);
 
       p += xsnprintf (p, endp - p, ":");
       p = write_ptid (p, endp, nptid);
@@ -5162,7 +5162,7 @@ remote_stop_ns (ptid_t ptid)
 
       if (ptid_is_pid (ptid))
 	  /* All (-1) threads of process.  */
-	nptid = ptid_build (ptid_get_pid (ptid), 0, -1);
+	nptid = ptid_build (ptid_get_pid (ptid), -1, 0);
       else
 	{
 	  /* Small optimization: if we already have a stop reply for
@@ -9314,7 +9314,7 @@ threadalive_test (char *cmd, int tty)
 {
   int sample_thread = SAMPLE_THREAD;
   int pid = ptid_get_pid (inferior_ptid);
-  ptid_t ptid = ptid_build (pid, 0, sample_thread);
+  ptid_t ptid = ptid_build (pid, sample_thread, 0);
 
   if (remote_thread_alive (ptid))
     printf_filtered ("PASS: Thread alive test\n");
@@ -9462,10 +9462,10 @@ remote_pid_to_str (struct target_ops *ops, ptid_t ptid)
 	xsnprintf (buf, sizeof buf, "Thread <main>");
       else if (rs->extended && remote_multi_process_p (rs))
 	xsnprintf (buf, sizeof buf, "Thread %d.%ld",
-		   ptid_get_pid (ptid), ptid_get_tid (ptid));
+		   ptid_get_pid (ptid), ptid_get_lwp (ptid));
       else
 	xsnprintf (buf, sizeof buf, "Thread %ld",
-		   ptid_get_tid (ptid));
+		   ptid_get_lwp (ptid));
       return buf;
     }
 }
@@ -12318,11 +12318,11 @@ stepping is supported by the target.  The default is on."),
   /* Eventually initialize fileio.  See fileio.c */
   initialize_remote_fileio (remote_set_cmdlist, remote_show_cmdlist);
 
-  /* Take advantage of the fact that the LWP field is not used, to tag
+  /* Take advantage of the fact that the TID field is not used, to tag
      special ptids with it set to != 0.  */
-  magic_null_ptid = ptid_build (42000, 1, -1);
-  not_sent_ptid = ptid_build (42000, 1, -2);
-  any_thread_ptid = ptid_build (42000, 1, 0);
+  magic_null_ptid = ptid_build (42000, -1, 1);
+  not_sent_ptid = ptid_build (42000, -2, 1);
+  any_thread_ptid = ptid_build (42000, 0, 1);
 
   target_buf_size = 2048;
   target_buf = xmalloc (target_buf_size);
-- 
1.7.11.7

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [PATCH 2/2] common/ptid.h: Mention that process_stratum targets should prefer ptid.lwp.
  2014-02-12 14:07 [PATCH 0/2] remote.c: ptid.tid -> ptid.lwp Pedro Alves
  2014-02-12 14:07 ` [PATCH 1/2] remote.c: Use the ptid.lwp field to store remote thread ids rather than ptid.tid Pedro Alves
@ 2014-02-12 14:07 ` Pedro Alves
  2014-02-19 19:09 ` [PATCH 0/2] remote.c: ptid.tid -> ptid.lwp Pedro Alves
  2 siblings, 0 replies; 7+ messages in thread
From: Pedro Alves @ 2014-02-12 14:07 UTC (permalink / raw)
  To: gdb-patches

It's best that we standardize on process_stratum targets using the
ptid.lwp field to store thread ids.  The idea being leave the ptid.tid
field free for any thread_stratum target that might want to sit on
top.

gdb/
2014-02-12  Pedro Alves  <palves@redhat.com>

	* common/ptid.h (struct ptid): Mention that process_stratum
	targets should prefer ptid.lwp.
---
 gdb/common/ptid.h | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/gdb/common/ptid.h b/gdb/common/ptid.h
index 362882d..cc1825e 100644
--- a/gdb/common/ptid.h
+++ b/gdb/common/ptid.h
@@ -25,7 +25,12 @@
    consists of the process id (pid), lightweight process id (lwp) and
    thread id (tid).  When manipulating ptids, the constructors,
    accessors, and predicates declared in this file should be used.  Do
-   NOT access the struct ptid members directly.  */
+   NOT access the struct ptid members directly.
+
+   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.
+*/
 
 struct ptid
 {
-- 
1.7.11.7

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH 1/2] remote.c: Use the ptid.lwp field to store remote thread ids rather than ptid.tid.
  2014-02-12 14:07 ` [PATCH 1/2] remote.c: Use the ptid.lwp field to store remote thread ids rather than ptid.tid Pedro Alves
@ 2014-02-12 16:56   ` Tom Tromey
  2014-02-12 16:58     ` Pedro Alves
  2014-02-12 18:09   ` Doug Evans
  1 sibling, 1 reply; 7+ messages in thread
From: Tom Tromey @ 2014-02-12 16:56 UTC (permalink / raw)
  To: Pedro Alves; +Cc: gdb-patches

>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:

Pedro> I believe that on the GDB side too, it's best that we standardize on
Pedro> process_stratum targets using the ptid.lwp field to store thread ids.
Pedro> The idea being leave the ptid.tid field free for any thread_stratum
Pedro> target that might want to sit on top.

Thanks for doing this.

Pedro> Because remote.c is currently using ptid.tid, we can't make gdbserver
Pedro> and gdb share bits of remote-specific code that manipulates ptids.

Pedro reminded me that the functions in question are read_ptid and
write_ptid.

Tom

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH 1/2] remote.c: Use the ptid.lwp field to store remote thread ids rather than ptid.tid.
  2014-02-12 16:56   ` Tom Tromey
@ 2014-02-12 16:58     ` Pedro Alves
  0 siblings, 0 replies; 7+ messages in thread
From: Pedro Alves @ 2014-02-12 16:58 UTC (permalink / raw)
  To: Tom Tromey; +Cc: gdb-patches

On 02/12/2014 04:56 PM, Tom Tromey wrote:
> Pedro reminded me that the functions in question are read_ptid and
> write_ptid.

I'll add this to the commit log.

-- 
Pedro Alves

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH 1/2] remote.c: Use the ptid.lwp field to store remote thread ids rather than ptid.tid.
  2014-02-12 14:07 ` [PATCH 1/2] remote.c: Use the ptid.lwp field to store remote thread ids rather than ptid.tid Pedro Alves
  2014-02-12 16:56   ` Tom Tromey
@ 2014-02-12 18:09   ` Doug Evans
  1 sibling, 0 replies; 7+ messages in thread
From: Doug Evans @ 2014-02-12 18:09 UTC (permalink / raw)
  To: Pedro Alves; +Cc: gdb-patches

On Wed, Feb 12, 2014 at 6:06 AM, Pedro Alves <palves@redhat.com> wrote:
> From GDB's perspective, independently of how the target really
> implements threads, gdb/remote sees all threads as if kernel/system
> threads.  A rationale along theses lines led to gdbserver storing
> thread ids in ptid.lwp in all ports.
>
> I believe that on the GDB side too, it's best that we standardize on
> process_stratum targets using the ptid.lwp field to store thread ids.
> The idea being leave the ptid.tid field free for any thread_stratum
> target that might want to sit on top.
>
> Because remote.c is currently using ptid.tid, we can't make gdbserver
> and gdb share bits of remote-specific code that manipulates ptids.
>
> This patch thus makes remote.c use ptid.lwp instead of ptid.tid.
>
> Tested on x86_64 Fedora 17, w/ local gdbserver.
>
> gdb/
> 2014-02-12  Pedro Alves  <palves@redhat.com>
>
>         * remote.c (remote_thread_alive, write_ptid, read_ptid)
>         (read_ptid, remote_newthread_step, remote_threads_extra_info)
>         (remote_get_ada_task_ptid, append_resumption, remote_stop_ns)
>         (threadalive_test, remote_pid_to_str, _initialize_remote): Use the
>         ptid.lwp field to store remote thread ids rather than ptid.tid.

Awesome.  Thanks.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH 0/2] remote.c: ptid.tid -> ptid.lwp
  2014-02-12 14:07 [PATCH 0/2] remote.c: ptid.tid -> ptid.lwp Pedro Alves
  2014-02-12 14:07 ` [PATCH 1/2] remote.c: Use the ptid.lwp field to store remote thread ids rather than ptid.tid Pedro Alves
  2014-02-12 14:07 ` [PATCH 2/2] common/ptid.h: Mention that process_stratum targets should prefer ptid.lwp Pedro Alves
@ 2014-02-19 19:09 ` Pedro Alves
  2 siblings, 0 replies; 7+ messages in thread
From: Pedro Alves @ 2014-02-19 19:09 UTC (permalink / raw)
  To: gdb-patches

On 02/12/2014 02:06 PM, Pedro Alves wrote:

I've pushed this in now.

-- 
Pedro Alves

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2014-02-19 19:09 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-12 14:07 [PATCH 0/2] remote.c: ptid.tid -> ptid.lwp Pedro Alves
2014-02-12 14:07 ` [PATCH 1/2] remote.c: Use the ptid.lwp field to store remote thread ids rather than ptid.tid Pedro Alves
2014-02-12 16:56   ` Tom Tromey
2014-02-12 16:58     ` Pedro Alves
2014-02-12 18:09   ` Doug Evans
2014-02-12 14:07 ` [PATCH 2/2] common/ptid.h: Mention that process_stratum targets should prefer ptid.lwp Pedro Alves
2014-02-19 19:09 ` [PATCH 0/2] remote.c: ptid.tid -> ptid.lwp Pedro Alves

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