@@ -6799,6 +6799,25 @@ remote_notif_get_pending_events (struct notif_client *nc)
}
}
+/* Check if the specified stop reply is for a fork event. If it is,
+ update the corresponding thread to contain the pending follow
+ information required to identify it as the fork parent. */
+
+static void
+update_thread_if_fork_parent (struct stop_reply *stop_reply)
+{
+ ptid_t ptid;
+
+ ptid = stop_reply->ptid;
+ if (stop_reply->ws.kind == TARGET_WAITKIND_FORKED
+ || stop_reply->ws.kind == TARGET_WAITKIND_VFORKED)
+ {
+ struct thread_info *tp = find_thread_ptid (ptid);
+
+ tp->pending_follow = stop_reply->ws;
+ }
+}
+
/* Called when it is decided that STOP_REPLY holds the info of the
event that is to be returned to the core. This function always
destroys STOP_REPLY. */
@@ -6844,8 +6863,11 @@ process_stop_reply (struct stop_reply *stop_reply,
remote_thr->core = stop_reply->core;
remote_thr->stop_reason = stop_reply->stop_reason;
remote_thr->watch_data_address = stop_reply->watch_data_address;
- }
+ /* Make sure we record any pending fork events. */
+ update_thread_if_fork_parent (stop_reply);
+
+ }
stop_reply_xfree (stop_reply);
return ptid;
}
This patch fixes an internal error that occurs in gdb.threads/forking-threads-plus-breakpoint.exp: /blah/binutils-gdb/gdb/target.c:2723: internal-error: Can't determine the current address space of thread Thread 3170.3170 In default_thread_address_space, find_inferior_ptid couldn't find 3170.3170 because it had been overwritten in inferior_appeared, called as follows: inferior_appeared remote_add_inferior remote_notice_new_inferior remote_update_thread_list The cause of the problem was the following sequence of events: * GDB knows only about the main thread * the first fork event is reported to GDB, saved as pending_event * qXfer:threads_read gets the threads from the remote. remove_new_fork_children id's the fork child from the pending event and removes it from the list reported to GDB. All the rest of the threads, including the fork parent, are added to the GDB thread list. * GDB stops all the threads. All the stop events are pushed onto the stop reply queue behind the pending fork event. * remote_wait_ns calls queued_stop_reply and process_stop_reply to remove the fork event from the front of the stop reply queue and save event information in the thread_info structure for the fork parent thread. Unfortunately, none of the information saved in this way is the fork-specific information, so the actual fork event info is lost. * A subsequent qXfer:threads:read packet gets the thread list including the fork parent and fork child. remove_new_fork_children checks the thread list to see if there is a fork parent, doesn't find one, checks the stop reply queue for a pending fork event, doesn't find one, and allows the fork child thread to be reported to GDB before the fork event has been handled. remote_update_thread_list calls remote_notice_new_thread and overwrites the current (main) thread in inferior_appeared. GDB has now lost all knowledge of the main thread, and an internal error results. The fix was to make sure that when the stop reply was removed from the stop reply queuei, all of the necessary fork event information was stored in the parent thread structure. In process_stop_reply we call a new function, update_thread_if_fork_parent, to store the pending_follow information from the fork stop reply in the fork parent thread. Tested on x86_64 and Nios II Linux. No regressions, but more failures, which are addressed in subsequent patches in this patchset. Thanks, --Don gdb/ChangeLog: 2016-01-27 Don Breazeal <donb@codesourcery.com> PR remote/19496 * remote.c (update_thread_if_fork_parent): New function. (process_stop_reply): Call update_thread_if_fork_parent. --- gdb/remote.c | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-)