Remote debugging of multithreaded programs using gdbserver

Subhashini Nagarajan Rao
2002-04-19T12:56:38Z

[-- 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.
********************************************************************