From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117989 invoked by alias); 27 Jun 2016 22:32:14 -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 117961 invoked by uid 89); 27 Jun 2016 22:32:12 -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=promising, Perhaps 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; Mon, 27 Jun 2016 22:32:03 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id D0D07117061; Mon, 27 Jun 2016 18:32:01 -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 FZRkZLFi9EJ7; Mon, 27 Jun 2016 18:32:01 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id A96E711703B; Mon, 27 Jun 2016 18:32:01 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 1D93F428F4; Mon, 27 Jun 2016 15:32:00 -0700 (PDT) Date: Mon, 27 Jun 2016 22:32: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: <20160627223200.GF3295@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9170a848-2c63-0e42-a478-23753c1f495b@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2016-06/txt/msg00456.txt.bz2 > >> 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. 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? 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. -- Joel