Hi Daniel, 

  With reference to your comment on the PC-adjustment, we tried to avoid it and 
the design for that is given below. I had also tested with this change and things
are working fine. Requesting your valuable comments on this. 

In order to avoid the PC-adjustment for the threads other than the thread of 
interest (thread_to_cont), we can remember the stop_event for the other threads.
which may require the following, 
 i) A boolean, has_pending, in the threadid_info structure to denote that that 
   particular thread has got a trap event (due to hitting a breakpoint) pending. This 
   should be initialised to 0. 

(Note - in the details that follow, thread_to_cont refers to the thread of interest, 
                                               'tp' refers to a thread in the list of current threads in 
                                                the program maintained in 'threadid_list' )

The changes to be made are, 
 i) In stop_all_threads(), if it is found that a thread has hit a breakpoint 
    then set the boolean tp->has_pending. Remove the code corresponding 
    to cancelling of breakpoints. 
ii) Do not reset tp->status for the threads which has tp->has_pending set as 
    it will have the trap event recorded. (This will be automatically taken care of
    if the code corresponding to cancellation of breakpoints is removed). 

If a 's' packet is sent, it indicates that the current thread is single-stepped 
and hence the resume logic will be kept the same except that those threads 
having a pending event will not get resumed. 

If a 'c' packet is sent, it means the previous hit breakpoint is cleared and 
now we can look into the threads having a pending event. Select the first 
thread in the threadid_list having a tp->has_pending equal to 1 and update the 
thread_to_cont and the general_thread (so that we fetch the register info of the 
correct thread) to this thread id. Reset tp->has_pending to indicate its selection. 
As all the other threads are already stopped the prepare_resume_reply should be 
called with this updated thread_to_cont with status set to 'T'. 

An 's' or 'c' packet now will be similar to what is stated above. 

As the pending trap events are getting serviced whenever a 'c' packet is sent , this 
eliminates the need to have the arbitration logic of selecting the next thread to 
continue in the function select_event_pid(). [The arbitration logic is explained in the
approach document under the subtitle - Procedure of waiting for the inferior process to return the status.]

- Subha