Remote debugging of multithreaded programs using gdbserver

["Subhashini Nagarajan Rao" <subhashini.nagarajan@wipro.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2610 bytes --]

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


[-- Attachment #1.2: Type: text/html, Size: 4576 bytes --]

[-- Attachment #2: Wipro_Disclaimer.txt --]
[-- Type: text/plain, Size: 477 bytes --]

**************************Disclaimer************************************
Information contained in this E-MAIL being proprietary to Wipro Limited
is 'privileged' and 'confidential' and intended for use only by the
individual or entity to which it is addressed. You are notified that any
use, copying or dissemination of the information contained in the E-MAIL
in any manner whatsoever is strictly prohibited.
********************************************************************