From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 51026 invoked by alias); 31 Jul 2015 18:04:24 -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 51015 invoked by uid 89); 31 Jul 2015 18:04:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 31 Jul 2015 18:04:21 +0000 Received: from svr-orw-fem-06.mgc.mentorg.com ([147.34.97.120]) by relay1.mentorg.com with esmtp id 1ZLEfJ-0007mm-QE from Don_Breazeal@mentor.com ; Fri, 31 Jul 2015 11:04:17 -0700 Received: from [172.30.11.41] (147.34.91.1) by svr-orw-fem-06.mgc.mentorg.com (147.34.97.120) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 31 Jul 2015 11:04:17 -0700 Message-ID: <55BBB89B.8020101@codesourcery.com> Date: Fri, 31 Jul 2015 18:04:00 -0000 From: Don Breazeal User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Pedro Alves , Subject: Re: [PATCH/7.10 2/2] gdbserver: Fix non-stop / fork / step-over issues References: <1438362229-27653-1-git-send-email-palves@redhat.com> <1438362229-27653-3-git-send-email-palves@redhat.com> In-Reply-To: <1438362229-27653-3-git-send-email-palves@redhat.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-07/txt/msg00952.txt.bz2 On 7/31/2015 10:03 AM, Pedro Alves wrote: > Ref: https://sourceware.org/ml/gdb-patches/2015-07/msg00868.html > > This adds a test that has a multithreaded program have several threads > continuously fork, while another thread continuously steps over a > breakpoint. Wow. > > This exposes several intertwined issues, which this patch addresses: > Thanks again for digging into these issues. ---snip--- > > - The test runs with both "set detach-on-fork" on and off. When off, > it exercises the case of GDB detaching the fork child explicitly. > When on, it exercises the case of gdb resuming the child > explicitly. In the "off" case, gdb seems to exponentially become > slower as new inferiors are created. This is _very_ noticeable as > with only 100 inferiors gdb is crawling already, which makes the > test take quite a bit to run. For that reason, I've disabled the > "off" variant for now. Bummer. I was going to ask whether this use-case justifies disabling the feature completely, but since the whole follow-fork mechanism is of limited usefulness without exec events, the question is likely moot anyway. Do you have any thoughts about whether this slowdown is caused by the fork event machinery or by some more general gdbserver multiple inferior problem? Are you planning to look at the slowdown? Can I help out? I have an interest in having detach-on-fork 'off' enabled. :-S thanks --Don