From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 110844 invoked by alias); 5 Jul 2016 16:49:48 -0000 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 Received: (qmail 110834 invoked by uid 89); 5 Jul 2016 16:49:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=stepped X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 05 Jul 2016 16:49:42 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 111E01169FA; Tue, 5 Jul 2016 12:49:41 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id AkmPW4H1MzOY; Tue, 5 Jul 2016 12:49:41 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id DD0131169F4; Tue, 5 Jul 2016 12:49:40 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 15959428F4; Tue, 5 Jul 2016 09:49:39 -0700 (PDT) Date: Tue, 05 Jul 2016 16:49:00 -0000 From: Joel Brobecker To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: RFA/gdbserver: GDB internal-error debugging threaded program with breakpoint and forks Message-ID: <20160705164939.GK3295@adacore.com> References: <20160512171650.GC26324@adacore.com> <5734C06C.8040008@codesourcery.com> <20160623225935.GC3295@adacore.com> <20160624181152.GD3295@adacore.com> <31daa4d2-359d-db9a-e9c8-d7bfbb327570@redhat.com> <20160624223616.GE3295@adacore.com> <9170a848-2c63-0e42-a478-23753c1f495b@redhat.com> <20160627223200.GF3295@adacore.com> <1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2016-07/txt/msg00076.txt.bz2 > > a. Make gdbserver "hide" the threads that are children of forks > > until we've reported the corresponding fork event to GDB. > > > > Agreed, I think we need to do this. It's somewhat what > linux-nat.c does, except linux-nat.c hides the fork child > until target_follow_fork time. [...] > That said, I would still consider my current > > patch, as reporting the forks early allow us to either detach > > from them earlier. > > My usual thought process is this: imagine we had (a) already. Would we > have a particularly strong reason to complicate the code and do (b) on > its own? Seems like not. We could apply the same rationale for preferring > to report any other thread stopped at a breakpoint before the fork > events (so that we could move them past their breakpoints earlier). Or > always prefer the stepping thread, as that's the thread the user is most > interested in (*). Etc. > > (*) - IIRC, the reason we prefer a stepped thread first is for > correctness, not because that's what the user is focused in. It used > to be that if a step event got pending, and we reported some other > event first, later when the pending step event is finally reported as > a plain SIGTRAP, if the thread that had a pending step was now > continued instead of stepped, infrun wouldn't understanding what this > SIGTRAP was about, since the thread was no longer supposed to be > single-stepping, and would thus report the SIGTRAP to the user as a > spurious signal. With "maint set target-non-stop on", which is still > not the default with target remote, > infrun.c:clear_proceed_status_thread handles this scenario on the gdb > side and discards the single-step, but with plain all-stop, the > spurious SIGTRAP probably would still happen. I would have thought that we'd want GDB and GDBserver to be in sync as quickly as possible, so as to release the new inferiors, but I guess that doesn't really make any difference in practice. The issue with reporting SIGTRAP from an old single-step is even more convincing that my patch is actually wrong. Sigh... -- Joel