From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4128 invoked by alias); 5 Jun 2009 22:00:53 -0000 Received: (qmail 4101 invoked by uid 22791); 5 Jun 2009 22:00:52 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 05 Jun 2009 22:00:45 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n55M0g47019106; Fri, 5 Jun 2009 18:00:42 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n55M0fI6002704; Fri, 5 Jun 2009 18:00:41 -0400 Received: from opsy.redhat.com (vpn-12-153.rdu.redhat.com [10.11.12.153]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n55M0exq025738; Fri, 5 Jun 2009 18:00:40 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 748D2378615; Fri, 5 Jun 2009 16:00:39 -0600 (MDT) To: "Ulrich Weigand" Cc: gdb-patches@sourceware.org Subject: Re: [03/19] set_longjmp_breakpoint References: <200906052115.n55LF2H7027202@d12av02.megacenter.de.ibm.com> From: Tom Tromey Reply-To: tromey@redhat.com Date: Fri, 05 Jun 2009 22:00:00 -0000 In-Reply-To: <200906052115.n55LF2H7027202@d12av02.megacenter.de.ibm.com> (Ulrich Weigand's message of "Fri\, 5 Jun 2009 23\:15\:02 +0200 \(CEST\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2009-06/txt/msg00138.txt.bz2 >>>>> "Ulrich" == Ulrich Weigand writes: Ulrich> As a side effect, if multiple objfiles provide longjmp, *all* Ulrich> instances will now get the breakpoint installed -- this may actually Ulrich> be useful in some circumstances (e.g. multiple SPE images in a Cell/B.E. Ulrich> application). This seems reasonable to me, but I am somewhat concerned about performance. I think this patch means that every "next" will involve looking up four symbols in every objfile. Do you know how big an effect this has? Or maybe Paul could try it on his famous kilo-.so program. I suppose if that is very slow we could add some kind of per-inferior cache.. ? Tom