From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20638 invoked by alias); 14 Mar 2013 19:55:15 -0000 Received: (qmail 20626 invoked by uid 22791); 14 Mar 2013 19:55:13 -0000 X-SWARE-Spam-Status: No, hits=-7.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_BJ X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 14 Mar 2013 19:55:04 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r2EJt1Co027021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Mar 2013 15:55:01 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r2EJsx49020848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 14 Mar 2013 15:55:00 -0400 From: Tom Tromey To: Jan Kratochvil Cc: Aleksandar Ristovski , "gdb-patches\@sourceware.org" Subject: Re: [draft patch 0/6] Split FYI and some review notes References: <51278984.3070208@qnx.com> <20130310210734.GA21130@host2.jankratochvil.net> <513DE949.6030508@qnx.com> <20130311150700.GA12857@host2.jankratochvil.net> <20130314184308.GC7696@blade.wire.rat> Date: Thu, 14 Mar 2013 19:55:00 -0000 In-Reply-To: <20130314184308.GC7696@blade.wire.rat> (Gary Benson's message of "Thu, 14 Mar 2013 18:43:08 +0000") Message-ID: <87hakd4uzw.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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 X-SW-Source: 2013-03/txt/msg00651.txt.bz2 >>>>> "Gary" == Gary Benson writes: Gary> Note that since Tom's ambiguous linespec work went in GDB needs to Gary> update its list at every change. You could seriously speed things up Gary> if you could eliminate this need--I considered making it asynchronous Gary> at one point, but couldn't get around it. The plan is for the itset work to help with this; plus also perhaps making a new objfile-limiting linespec, like "break libwhatever.so:function". itsets will let us restrict the lookups to a given set of program spaces; those left out will not have to have libraries loaded. The linespec change will let us avoid loading debuginfo for other libraries. This may also need fine-grained breakpoint re-setting. I filed this in bugzilla recently. I think the linespec thing is in there somewhere too. This approach assumes that the user knows about these things and cares about gdb performance. So maybe another tradeoff is better. On balance I tend to still like the ambiguous linespec approach, since I tend to think predictability and uniformity is more important to more users than debugger performance. FWIW if you have patches to improve laziness, you can maybe test them by arranging for your test program to crash -- don't set any breakpoints at all. Tom