I found these bugs recently while debugging against an am33 target. One
is a fairly old bug and was likely not noticed 'til now due to the fact
that a software singlestep target is required to see it.
The other bug is one that I introduced recently when I revised thread-db.c
to not always update the thread list.
* thread-db.c (handle_thread_db_event): Allow underlying target a
chance to look at the wait status too.
(thread_db_check_child_state): Ensure that there's a thread list
to work with when using the thread_db event model.
RCS file: /cvs/src/src/rda/unix/thread-db.c,v
retrieving revision 1.16
diff -u -p -r1.16 thread-db.c
--- thread-db.c 8 Nov 2005 21:58:36 -0000 1.16
+++ thread-db.c 2 Dec 2005 00:48:28 -0000
@@ -1853,6 +1853,9 @@ handle_thread_db_event (struct child_pro
/* We don't have any new status to report... */
+ /* Give underlying target a chance to look at the wait status. This
+ is necessary for software singlestep to work correctly. */
+ handle_waitstatus (process, w);
- /* Update the thread list, and attach to (and thereby stop)
- any new threads we find. */
- update_thread_list (process);
+ /* The thread_db event model requires that `event_thread' (see
+ below) gets set correctly, but this won't happen unless there's
+ a thread list to search. So, if the thread_list is empty and
+ we're using the thread_db event model, we need to update the
+ thread list. */
+ if (thread_list == NULL && using_thread_db_events)
+ /* Update the thread list, and attach to (and thereby stop)
+ any new threads we find. */
+ update_thread_list (process);