From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14323 invoked by alias); 7 May 2013 15:24:05 -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 14266 invoked by uid 89); 7 May 2013 15:24:05 -0000 X-Spam-SWARE-Status: No, score=-6.3 required=5.0 tests=AWL,BAYES_00,FAKE_REPLY_C,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 07 May 2013 15:24:05 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r47FO2KJ003734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 May 2013 11:24:03 -0400 Received: from host2.jankratochvil.net (ovpn-116-69.ams2.redhat.com [10.36.116.69]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r47E0Lnm005768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 7 May 2013 10:00:24 -0400 Date: Tue, 07 May 2013 15:24:00 -0000 From: Jan Kratochvil To: Doug Evans Cc: Tom Tromey , gdb-patches Subject: Re: [patch 2/2] Assert leftover cleanups in TRY_CATCH Message-ID: <20130507140020.GA10070@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2013-05/txt/msg00239.txt.bz2 On Tue, 07 May 2013 06:37:08 +0200, Doug Evans wrote: > but I don't see how inferior breakpoint slowness is related. It is very unrelated but it was illustrating there is still a lot of work on GDB to do. > [I can imagine a reason why multiple virtual class inheritance is related, > but then again I'm not sure I'd want to see gdb use it itself.] I do not know if there is a use case in GDB really worth it; it was again just an illustration there is still a lot of work on GDB to do. > btw, is the slowness just an all-stop thing? > Or is there room for massive improvement in non-stop too? It was single-threaded mode. On Tue, 07 May 2013 06:49:48 +0200, Doug Evans wrote: > I'm setting aside target-side condition evaluation of course. target-side condition evaluation is a good idea: time gdb ./loop -ex 'b 4 if i==360000' -ex r -q -ex 'set confirm no' -ex q real 1m11.586s gdbserver :1234 ./loop time gdb ./loop -ex 'target remote localhost:1234' -ex 'b 4 if i==360000' -ex c -q -ex 'set confirm no' -ex q real 0m21.862s "set breakpoint condition-evaluation target" really helps a lot. Although recompilation with a compiled-in conditional is still faster. loop.c: -------------------- #include int main(void) { for (int i=0;;i++) if (i==360000) break; return 0; } Regards, Jan