From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13022 invoked by alias); 19 Apr 2002 12:56:38 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 12912 invoked from network); 19 Apr 2002 12:56:30 -0000 Received: from unknown (HELO wiprom2mx1.wipro.com) (203.197.164.41) by sources.redhat.com with SMTP; 19 Apr 2002 12:56:30 -0000 Received: from m2vwall2.wipro.com ([164.164.29.236]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g3JCuRE06460 for ; Fri, 19 Apr 2002 18:26:27 +0530 (IST) Received: from subshahini ([192.127.177.104]) by platinum.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GUTFXV00.S80 for ; Fri, 19 Apr 2002 18:26:19 +0530 Message-ID: <097c01c1e7a2$6f484510$68b17fc0@wipro.com> From: "Subhashini Nagarajan Rao" To: Subject: Remote debugging of multithreaded programs using gdbserver Date: Fri, 19 Apr 2002 05:56:00 -0000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-970c49e8-5388-11d6-af80-0080c8048dde" X-Priority: 3 X-MSMail-Priority: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-SW-Source: 2002-04/txt/msg00328.txt.bz2 This is a multi-part message in MIME format. ------=_NextPartTM-000-970c49e8-5388-11d6-af80-0080c8048dde Content-Type: multipart/alternative; boundary="----=_NextPart_000_0979_01C1E7D0.88D8D4D0" ------=_NextPart_000_0979_01C1E7D0.88D8D4D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-length: 2668 Hi Daniel,=20 With reference to your comment on the PC-adjustment, we tried to avoid it= and=20 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.=20 In order to avoid the PC-adjustment for the threads other than the thread o= f=20 interest (thread_to_cont), we can remember the stop_event for the other thr= eads. which may require the following,=20 i) A boolean, has_pending, in the threadid_info structure to denote that t= hat=20 particular thread has got a trap event (due to hitting a breakpoint) pen= ding. This=20 should be initialised to 0.=20 (Note - in the details that follow, thread_to_cont refers to the thread of = interest,=20 'tp' refers to a thread in t= he list of current threads in=20 the program maintained in '= threadid_list' ) The changes to be made are,=20 i) In stop_all_threads(), if it is found that a thread has hit a breakpoin= t=20 then set the boolean tp->has_pending. Remove the code corresponding=20 to cancelling of breakpoints.=20 ii) Do not reset tp->status for the threads which has tp->has_pending set a= s=20 it will have the trap event recorded. (This will be automatically taken= care of if the code corresponding to cancellation of breakpoints is removed).=20 If a 's' packet is sent, it indicates that the current thread is single-ste= pped=20 and hence the resume logic will be kept the same except that those threads= =20 having a pending event will not get resumed.=20 If a 'c' packet is sent, it means the previous hit breakpoint is cleared an= d=20 now we can look into the threads having a pending event. Select the first=20 thread in the threadid_list having a tp->has_pending equal to 1 and update = the=20 thread_to_cont and the general_thread (so that we fetch the register info o= f the=20 correct thread) to this thread id. Reset tp->has_pending to indicate its se= lection.=20 As all the other threads are already stopped the prepare_resume_reply shoul= d be=20 called with this updated thread_to_cont with status set to 'T'.=20 An 's' or 'c' packet now will be similar to what is stated above.=20 As the pending trap events are getting serviced whenever a 'c' packet is se= nt , this=20 eliminates the need to have the arbitration logic of selecting the next thr= ead to=20 continue in the function select_event_pid(). [The arbitration logic is expl= ained in the approach document under the subtitle - Procedure of waiting for the inferio= r process to return the status.] - Subha ------=_NextPart_000_0979_01C1E7D0.88D8D4D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-length: 4748
Hi Daniel,
 
  With reference to your comment on t= he=20 PC-adjustment, we tried to avoid it and
the design for that is given below. I= had also=20 tested with this change and things
are working fine. Requesting your valuable= comments=20 on this.
 
In order to avoid the PC-adjustment for th= e threads=20 other than the thread of
interest (thread_to_cont), we can remember the= =20 stop_event for the other threads.
which may require the following,=20
 i) A boolean, has_pending, in the threadid_info structure to deno= te=20 that that
   particular thread has got a t= rap event=20 (due to hitting a breakpoint) pending. This
   should be initialised to 0.=20
(Note - in the details that follow, thread= _to_cont=20 refers to the thread of interest,
           =             &nb= sp;            =           =20 'tp' refers to a thread in the list of current threads in
           =             &nb= sp;            =             the= =20 program maintained in 'threadid_list' )

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

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

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

An 's' or 'c' packet now will be similar to what is sta= ted=20 above.
 
As the pending trap events are getting ser= viced=20 whenever a 'c' packet is sent , this
eliminates the need to have the arbitratio= n logic=20 of selecting the next thread to
continue in the function select_event_pid(= ). [The=20 arbitration logic is explained in the
approach document under the subtitle - Pro= cedure of=20 waiting for the inferior process to return the status.]
 
- Subha
 
------=_NextPart_000_0979_01C1E7D0.88D8D4D0-- ------=_NextPartTM-000-970c49e8-5388-11d6-af80-0080c8048dde Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-length: 477 **************************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. ******************************************************************** ------=_NextPartTM-000-970c49e8-5388-11d6-af80-0080c8048dde--