From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23135 invoked by alias); 8 Jun 2009 14:48:34 -0000 Received: (qmail 23120 invoked by uid 22791); 8 Jun 2009 14:48:33 -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; Mon, 08 Jun 2009 14:48:26 +0000 Received: (qmail 5513 invoked from network); 8 Jun 2009 14:48:24 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 8 Jun 2009 14:48:24 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [00/19] Eliminate some more current_gdbarch uses Date: Mon, 08 Jun 2009 14:48:00 -0000 User-Agent: KMail/1.9.10 Cc: "Ulrich Weigand" , tromey@redhat.com References: <200906081438.n58EcdKE022828@d12av02.megacenter.de.ibm.com> In-Reply-To: <200906081438.n58EcdKE022828@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200906081549.28627.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/msg00177.txt.bz2 On Monday 08 June 2009 15:38:39, Ulrich Weigand wrote: > Of course, this would mean the breakpoints were always active. =A0However, > this could be improved upon by: > - having infrun ignore longjmp breakpoints if not stepping If there isn't any thread doing a command that requires longjmp breakpoints, I'd really like to not have them inserted, it's inneficient for "continue". Plus, threads hit longjmps on their way to exiting (on linux/pthreads) --- and it's best to avoid it, with all the nasty longjmp issues (pointer mangling) we have. > - keeping them disabled unless stepping (and still have infrun ignore > =A0 longjmp breakpoints when hit in the wrong thread) Yeah, I can see that working. > and/or > - keeping them always disabled, but installing momentary clones in > =A0 threads that are stepping Yeah, sounds sort of good too. I've added a momentary breakpoint cloning function just a few days ago. This requires looking up which threads in the same address space are stepping. I'm not certain which version would be uglier. Currently, it's the address lookup part that's ineficient. We could tackle that with per-objfile data, without making the breakpoints module much aware of stepping. --=20 Pedro Alves