From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 42297 invoked by alias); 28 Jun 2016 19:40:15 -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 42288 invoked by uid 89); 28 Jun 2016 19:40:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=maint X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 28 Jun 2016 19:40:12 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9900F6408A; Tue, 28 Jun 2016 19:40:11 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5SJeAtZ029694; Tue, 28 Jun 2016 15:40:10 -0400 Subject: Re: RFA/gdbserver: GDB internal-error debugging threaded program with breakpoint and forks To: Joel Brobecker 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> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com> Date: Tue, 28 Jun 2016 19:40:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160627223200.GF3295@adacore.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-06/txt/msg00472.txt.bz2 On 06/27/2016 11:32 PM, Joel Brobecker wrote: >>>> I haven't gone through this with fine-tooth comb yet, but, >>>> will we still have the same problem if _two_ threads (or inferiors...) >>>> fork at the "same" time, and we end up reporting one fork, while >>>> leaving the another one pending? >>> >>> At the moment, I do not think so, because we seem to just process >>> the fork even without requesting an update of the thread list. >> >> "catch fork" would make us stop though. > > :-(. Most likely. I had the weekend to mull this over. The only > possible solutions I can see are: > > 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. I say similar, instead of "just like", because the RSP doesn't have a "follow fork / detach fork" concept. That's because the model of instead making the child visible as a regular process as soon as we see the parent fork allows using regular detach, remove breakpoints, etc. packets against the fork child. We could make the server always hide the child until it gets some new "unhide child now" packet, but I think all it would avoid is gdb looking over the already-reported events and check whether a fork is pending, so it seems unnecessary. > But then, I think it's unclear what to do if the user does > a "step" or "continue" while you have multiple pending > fork events. That's probably a question that's likely not > specific to forks, as you might have the same issue when > requesting an action after seeing the first of multiple > events received at the same time. Perhaps simply just return > the next event without resuming anything? Is that what we do? Yes, that's what we do. For gdb there's no difference between the other pending event having happened to trigger at the same time as the last reported event, vs it triggering immediately on next resume. > > b. Somehow enhance GDB to handle the extra unknown threads > more gracefully. > > I don't really see how (b) could work. It seems that (a) would > be more promising. 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. Thanks, Pedro Alves