From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6723 invoked by alias); 6 May 2008 18:12:26 -0000 Received: (qmail 6705 invoked by uid 22791); 6 May 2008 18:12:25 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 06 May 2008 18:12:00 +0000 Received: (qmail 3022 invoked from network); 6 May 2008 18:11:55 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 6 May 2008 18:11:55 -0000 From: Pedro Alves To: "Ulrich Weigand" Subject: Re: [RFA] Make continuations per-thread. Date: Tue, 06 May 2008 19:02:00 -0000 User-Agent: KMail/1.9.9 Cc: Daniel Jacobowitz , Vladimir Prus , gdb-patches@sourceware.org References: <200805021519.m42FJ6bd009452@d12av02.megacenter.de.ibm.com> In-Reply-To: <200805021519.m42FJ6bd009452@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200805061911.52375.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-05/txt/msg00246.txt.bz2 A Friday 02 May 2008 16:19:06, Ulrich Weigand wrote: > Note that current GDB is really broken when it comes to handling > step / next operations that are interrupted by an event in some > other thread. There is some code to "context switch" the stepping > status, but this appears to be incomplete, and leads to inconsistent > results; e.g. GDB can run into internal assertion failures like > "Thread Event Breakpoint: gdb should not stop!" (see PR 2250). > > I'm currently carrying the following patch in our GDB builds that > fixes the issue be ensuring: > Thanks for showing us that. > - If the step operation is interrupted by an *internal* breakpoint > that is handled transparently, the operation continues in a > transparent and consistent manner after the breakpoint was handled. > > - If the step operation is interrupted by an *explicit* breakpoint > that breaks to a user prompt, it is completely cancelled. It is > then up to the user how to continue from the prompt. > A agree that this behaviour is sensible in all-stop (what we have now) mode. I tried your patch, and the bahaviour makes sense to me. Note, however, that in non-stop mode, we need to retain the stepping state per-thread (and actually make a few more things per-thread), so we'd like to keep the variables you're removing from struct thread_info in some form. http://sourceware.org/ml/gdb-patches/2008-05/msg00232.html > Now it looks like the second point is in conflict to the goal you > are proposing here (namely, that even after a user prompt, the > interrupted step/next/finish still continues in some manner). > I'm not sure how this could be accomplished ... > Our major goal is to have that in non-stop mode. It seemed we would win some of it for free in all-stop mode, but it turned out it isn't so. Thanks! -- Pedro Alves