From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12303 invoked by alias); 5 Jun 2009 23:30:33 -0000 Received: (qmail 12264 invoked by uid 22791); 5 Jun 2009 23:30:32 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 05 Jun 2009 23:30:24 +0000 Received: (qmail 31418 invoked from network); 5 Jun 2009 23:30:23 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 5 Jun 2009 23:30:23 -0000 From: Pedro Alves To: tromey@redhat.com Subject: Re: [00/19] Eliminate some more current_gdbarch uses Date: Fri, 05 Jun 2009 23:30:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb-patches@sourceware.org, "Ulrich Weigand" References: <200906052113.n55LDMj4025990@d12av02.megacenter.de.ibm.com> <200906052325.03584.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906060031.14803.pedro@codesourcery.com> X-IsSubscribed: yes 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/msg00146.txt.bz2 On Friday 05 June 2009 23:52:25, Tom Tromey wrote: > >>>>> "Pedro" == Pedro Alves writes: > > Pedro> - We should do something smarter about longjmp breakpoint > Pedro> lookup at some point. > > If you have something in mind, I would like to hear it. > The next-over-throw patch does something very similar to the longjmp > code; I would be happy to update both at once. I *know* we can do smarter, but exactly what's the best, I haven't thought much about. Some data points / suggestions: - longjmp breakpoints need to be installed as long as there's a thread nexting or stepping or whatever command that needs those, for non-stop mode. The fact that they're momentary breakpoints makes it so that a thread that is "continue"ing, simply thread hops them, since momentary breakpoints are thread specific, which is more efficient than having them all set longjmp-resume, hit-longjmp-resume,resume. The breakpoint location machinery takes care of not installing duplicates. The set of addresses where to install such breakpoints however, don't change per-address space --- we could cache minimal symbols on a per symbol/address space generic framework (similar to objfile_data), and reparse that only when symbols change (that is, breakpoint_re_set or similar). - perhaps the simplest and most likely the most effective easily: we can use the objfile_data mechanism to cache if there are longjmp-like functions in a given objfile. No use looking up the minimal symbol everytime. - lookup_minimal_symbol still does a linear walk on all objfiles when you pass it an objfile. That may matter a bit. We could split that function in two to not do that loop when we know the objfile in advance. - we can move the update_global_location_list to the caller of create_longjmp_breakpoint, cutting its frequency by 4, if that matters. Probably not currently. -- Pedro Alves