This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH] linux-thread-db.c: super small optimization


I'm checking this in.

While doing other changes, I ended up noticing we're going over the
thread list twice for no reason.

Tested on x86_64 Fedora 16.

2012-03-02  Pedro Alves  <palves@redhat.com>

	* linux-thread-db.c (attach_thread): Avoid in_thread_list call.
---
 0 files changed, 0 insertions(+), 0 deletions(-)

diff --git a/gdb/linux-thread-db.c b/gdb/linux-thread-db.c
index b64ac2e..ea34bf4 100644
--- a/gdb/linux-thread-db.c
+++ b/gdb/linux-thread-db.c
@@ -1116,7 +1116,7 @@ attach_thread (ptid_t ptid, const td_thrhandle_t *th_p,
 	       const td_thrinfo_t *ti_p)
 {
   struct private_thread_info *private;
-  struct thread_info *tp = NULL;
+  struct thread_info *tp;
   td_err_e err;
   struct thread_db_info *info;
 
@@ -1130,11 +1130,9 @@ attach_thread (ptid_t ptid, const td_thrhandle_t *th_p,
      thread ID.  In the first case we don't need to do anything; in
      the second case we should discard information about the dead
      thread and attach to the new one.  */
-  if (in_thread_list (ptid))
+  tp = find_thread_ptid (ptid);
+  if (tp != NULL)
     {
-      tp = find_thread_ptid (ptid);
-      gdb_assert (tp != NULL);
-
       /* If tp->private is NULL, then GDB is already attached to this
 	 thread, but we do not know anything about it.  We can learn
 	 about it here.  This can only happen if we have some other


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]