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]

Re: [PATCH v2] Remove support for thread events without PTRACE_EVENT_CLONE in GDB.




On 12/10/2015 12:59 PM, Pedro Alves wrote:
On 12/10/2015 05:57 PM, Antoine Tremblay wrote:


On 12/10/2015 12:45 PM, Pedro Alves wrote:
On 12/10/2015 03:49 PM, Antoine Tremblay wrote:

Pushed in. (Without the dot at the end of the subject)

This broke corethreads.exp though:

Running /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.threads/corethreads.exp ...
FAIL: gdb.threads/corethreads.exp: thread0 found
FAIL: gdb.threads/corethreads.exp: thread1 found


Right, somehow my buildbot did not see it :(

I'm looking into it now.


It's this hunk:

@@ -1627,24 +1226,7 @@ find_new_threads_callback (const td_thrhandle_t *th_p, void *data)
    ptid = ptid_build (info->pid, ti.ti_lid, 0);
    tp = find_thread_ptid (ptid);
    if (tp == NULL || tp->priv == NULL)
-    {
-      if (attach_thread (ptid, th_p, &ti))
-       cb_data->new_threads += 1;
-      else
-       /* Problem attaching this thread; perhaps it exited before we
-          could attach it?
-          This could mean that the thread list inside glibc itself is in
-          inconsistent state, and libthread_db could go on looping forever
-          (observed with glibc-2.3.6).  To prevent that, terminate
-          iteration: thread_db_find_new_threads_2 will retry.  */
-       return 1;
-    }
-  else if (target_has_execution && !thread_db_use_events ())
-    {
-      /* Need to update this if not using the libthread_db events
-        (particularly, the TD_DEATH event).  */
-      update_thread_state (tp->priv, &ti);
-    }
+    thread_from_lwp (ptid);

    return 0;
  }

We can't use thread_from_lwp with core files.  As mentioned in a comment,
td_ta_map_lwp2thr uses ps_get_thread_area, but we can't use that
currently on core targets, as it uses ptrace directly.

Right, I think I can replace that directly with :

  if (tp == NULL || tp->priv == NULL)
      record_thread (info, tp, ptid, th_p, &ti);

Sounds ok ? (it fixes the test)

I'll run the full testsuite...



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