This is the mail archive of the 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]

Remote debugging of multithreaded programs using gdbserver

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: Wipro_Disclaimer.txt
Description: Text document

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