From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25527 invoked by alias); 19 Apr 2002 16:16:31 -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 25460 invoked from network); 19 Apr 2002 16:16:23 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 19 Apr 2002 16:16:23 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16yb3v-0006Q7-00; Fri, 19 Apr 2002 12:16:39 -0400 Date: Fri, 19 Apr 2002 09:16:00 -0000 From: Daniel Jacobowitz To: Subhashini Nagarajan Rao Cc: gdb@sources.redhat.com Subject: Re: Remote debugging of multithreaded programs using gdbserver Message-ID: <20020419121639.B24030@nevyn.them.org> Mail-Followup-To: Subhashini Nagarajan Rao , gdb@sources.redhat.com References: <097c01c1e7a2$6f484510$68b17fc0@wipro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <097c01c1e7a2$6f484510$68b17fc0@wipro.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-04/txt/msg00332.txt.bz2 On Fri, Apr 19, 2002 at 06:32:17PM +0530, Subhashini Nagarajan Rao wrote: > 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). I reached the point in my implementation where I needed this code yesterday. I got it to work, but in the process gained a good understanding for why it is done the other way in core GDB - because otherwise, if a breakpoint is removed after two threads have hit it, one of them will resume with the wrong PC and a bogus SIGTRAP. You should be able to reproduce this with pthreads.c in the GDB testsuite, by setting a breakpoint on common_function if hits >= 15, continuing to it, disabling the breakpoint, and continuing again. That most likely requires SMP in order to see it; I highly recommend testing all thread-debugging work on SMP. I think that this approach is still valuable, because it simplifies the arbitration logic, but backing off of breakpoints may still be necessary. > **************************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. > ******************************************************************** This form of disclaimer violates the accepted policy for most mailing lists; the GCC lists page explicitly says: |Please do not include or reference confidentiality notices, like: | | The referring document contains privileged and confidential | information. If you are not the intended recipient you must not | disseminate, copy or take any action in reliance on it, and we request | that you notify companyname immediately. | |Such disclaimers are inappropriate for mail sent to public lists. If |your company automatically adds something like this to outgoing mail, |and you can't convince them to stop, you might consider using a free |web-based e-mail account. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer