From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 365 invoked by alias); 20 Jul 2010 21:03:54 -0000 Received: (qmail 32679 invoked by uid 22791); 20 Jul 2010 21:03:53 -0000 X-SWARE-Spam-Status: No, hits=-6.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,TW_BJ,T_RP_MATCHES_RCVD 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; Tue, 20 Jul 2010 21:03:47 +0000 Received: from int-mx04.intmail.prod.int.phx2.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.17]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o6KL3jBa028852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Jul 2010 17:03:45 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx04.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o6KL3iCh008771; Tue, 20 Jul 2010 17:03:45 -0400 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id o6KL3ioL009044; Tue, 20 Jul 2010 17:03:44 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id CB1273797EE; Tue, 20 Jul 2010 15:03:43 -0600 (MDT) From: Tom Tromey To: Justin Lebar Cc: gdb-patches@sourceware.org Subject: Re: [Patch] Bug 8287: Skip uninteresting functions while debugging References: Date: Tue, 20 Jul 2010 21:03:00 -0000 In-Reply-To: (Justin Lebar's message of "Mon, 28 Jun 2010 10:43:49 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.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: 2010-07/txt/msg00318.txt.bz2 >>>>> "Justin" == Justin Lebar writes: Tom> One concern of mine is that this code will not perform well with many Tom> blacklists in place. It may make sense to keep a hash table indexed by Tom> name (function or file), to make lookups faster. What do you think? Justin> I imagine you'd have to have a pretty large blacklist to notice Justin> a delay when using gdb interactively, even on modest hardware. Justin> I don't know much about gdb scripting -- this might matter more Justin> in that case. But would one single-step in a script? Justin> FWIW, enabling/disabling/deleting breakpoints takes time linear Justin> to the number of breakpoints. Yeah, good points, let's just leave it as is. Tom> Another random thought is whether we want to be able to blacklist based Tom> on objfile name. Justin> That seems like it might be nice. Regular expression matching Justin> on file and function names has also been suggested. All good ideas; it is fine to defer these if you'd rather. Justin> While I'm thinking about it, one problem I've run into while Justin> using this patch while debugging Firefox is that we somehow load Justin> multiple copies of our smart pointer header, so I have to Justin> blacklist both ../../nsCOMPtr.h and ../../../nsCOMPtr.h. I need Justin> to investigate further exactly what about our build system is Justin> causing this to see if it's something which should be fixed in Justin> gdb or Mozilla's build, but my guess is that we may want to Justin> support this in gdb somehow. Allowing regular expressions is a solid gdb tradition. Justin> This patch also fixes bug 11614: decode_variable() in linespec.c Justin> does not obey its contract Tom> It is somewhat preferred in gdb to submit things like this as separate Tom> patches. Justin> I've split them out in this new set. Because you need the Justin> bug11614 patch in order for the blacklist patch to work (and Justin> since bug11614 is a trivial fix), I've included both attachments Justin> in this one e-mail. This patch is ok. Please check it in. Mention the PR in the ChangeLog entry, like: 2010-06-25 Justin Lebar PR gdb/11614: * linespec.c (decode_variable): Passing a non-null not_found_ptr [...] If you do this, and then use the ChangeLog entry as the commit message, the commit will show up in bugzilla. Justin> + if (b->pc != 0) Justin> + ui_out_field_core_addr (uiout, "addr", b->gdbarch, b->pc); /* 4 */ Justin> + else Justin> + ui_out_field_string (uiout, "addr", "n/a"); /* 4 */ Justin> + } Tom> A small nit, but I'm not sure about the exact string "n/a" here. Tom> If there is an analogous situation elsewhere it would be good to just do Tom> whatever is done there. Justin> We could just use the empty string if that would be clearer. Yeah, I think so. Justin> + /* First, check whether the file or function this entry is pending on has Justin> + been loaded. It might be more sensible to do this on a solib load, Justin> + but that doesn't seem to work for some reason. */ Tom> Let's figure this out. Justin> I spent a while in #gdb with a few people (I don't recall who) Justin> and we couldn't figure this out. I added a solib load observer, Justin> but from within it, find_pc_partial_function always failed. Justin> I'm not sure where to look to figure out what's going on. Offhand I'm not sure either, I think all you can do is debug the particular call. Tom> Also, since the blacklist includes a PC value, I think you have to reset Tom> it when re-running the inferior, and on some other state changes as well. Justin> Hm. How do we handle this with breakpoints? See breakpoint_re_set. Tom> I think it would be more usual to make the commands "enable blacklist ..." Tom> instead of "blacklist enable ...". Likewise for disable and delete. Justin> I'm not sure I like "enable blacklist". The problem is that Justin> "blacklist" is a noun referring to the list of all functions we Justin> skip and also a verb meaning "add an entry to the blacklist". Justin> "Enable blacklist" sounds to me like we're enabling an entire Justin> list of blacklist entries. Yeah, that makes sense. Justin> Maybe we can name the thing which indicates that we shouldn't Justin> step into a function something less confusing than a "blacklist Justin> entry"? Yes, that would be good. Any ideas for names? Tom