From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14136 invoked by alias); 8 Jun 2009 14:38:57 -0000 Received: (qmail 14119 invoked by uid 22791); 8 Jun 2009 14:38:55 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtagate3.de.ibm.com (HELO mtagate3.de.ibm.com) (195.212.29.152) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 08 Jun 2009 14:38:47 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.14.3/8.13.8) with ESMTP id n58Ecf5o151876 for ; Mon, 8 Jun 2009 14:38:41 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n58EceqO2486350 for ; Mon, 8 Jun 2009 16:38:40 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n58EcetZ022864 for ; Mon, 8 Jun 2009 16:38:40 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id n58EcdKE022828; Mon, 8 Jun 2009 16:38:39 +0200 Message-Id: <200906081438.n58EcdKE022828@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Mon, 08 Jun 2009 16:38:39 +0200 Subject: Re: [00/19] Eliminate some more current_gdbarch uses To: pedro@codesourcery.com (Pedro Alves) Date: Mon, 08 Jun 2009 14:38:00 -0000 From: "Ulrich Weigand" Cc: tromey@redhat.com, gdb-patches@sourceware.org In-Reply-To: <200906060031.14803.pedro@codesourcery.com> from "Pedro Alves" at Jun 06, 2009 12:31:14 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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/msg00175.txt.bz2 Pedro Alves wrote: > 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. I guess we could treat the longjmp breakpoint similarly to the overlay event breakpoint and recompute its address(es) only when objfiles change (i.e. in breakpoint_re_set_objfile). Of course, this would mean the breakpoints were always active. However, this could be improved upon by: - having infrun ignore longjmp breakpoints if not stepping - keeping them disabled unless stepping (and still have infrun ignore longjmp breakpoints when hit in the wrong thread) and/or - keeping them always disabled, but installing momentary clones in threads that are stepping > - 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. This might be useful anyway ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com