From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27057 invoked by alias); 3 May 2011 18:17:50 -0000 Received: (qmail 27020 invoked by uid 22791); 3 May 2011 18:17:48 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 03 May 2011 18:17:33 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id D64222BB11C; Tue, 3 May 2011 14:17:32 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RV+d5xLwuFjz; Tue, 3 May 2011 14:17:32 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id CD0A62BB118; Tue, 3 May 2011 14:17:31 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 6E1CB145615; Tue, 3 May 2011 11:17:27 -0700 (PDT) Date: Tue, 03 May 2011 18:17:00 -0000 From: Joel Brobecker To: Jerome Guitton Cc: Jan Kratochvil , Pedro Alves , gdb-patches@sourceware.org, Tom Tromey , Sergio Durigan Junior Subject: Re: [PATCH 2/6] Introduce `pre_expanded sals' Message-ID: <20110503181727.GO2489@adacore.com> References: <201104121218.08910.pedro@codesourcery.com> <20110412115308.GA384@host1.jankratochvil.net> <20110503160903.GA27067@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110503160903.GA27067@adacore.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2011-05/txt/msg00074.txt.bz2 I also wanted to say that, as it turns out, Jerome is here in Vancouver for the week with the goal of adding handling for homonyms in GDB. So the timing for this discussion could hardly be any better. The downside, if we want to be able to take better advantage of his trip is that a quick decision would be helpful so we can get started on sending out implementation proposals. I also wanted to give a summary of our discussions on this topic that occured yesterday, after we read all the threads. We went back and forth between Pedro's proposal and Tom's. We were trying to think from the user's perspective, and with a focus on C++ and Ada (we don't understand stap all that well, but hopefully it will also apply there). Right now, there are several situations that can lead to multiple breakpoint addresses: Generics/templates, homonyms (functions with the same name), and inlining. In Ada, we've traditionally treated generics & homonyms differently (multiple breakpoints created) from inlining (single breakpoint, multiple locations). But does it have to be that way? For homonyms, we feel that the typical case is that the user is usually interested in debugging on specific function. If there is a bunch of functions called "increment" but only one shows symptoms of a bug, that's the one that he really wants to break in. On the other hand, are generics and templates all that different from inlining? Thinking about typical debugging scenarios, though, we think it's common for someone to debug a specific instantiation of a generic, because it knows that this instantiation shows a bug, while the others are not. So it's important to be able to specify that a breakpoint applies to one specific instance, which means that we're leaning towards handling generics/templates the same as we'd handle homonyms. Pedro's idea of federating these SLOC-based breakpoints inside a 3rd-tier linespec-based breakpoint would probably work. But, as Jerome and I kept discussing, we felt that maybe it wasn't necessary. In terms of Ada itself, we've been able to work without them. Perhaps C++ usage is sufficiently different that the concept would be more interesting there? But do we need the 3rd-tier consolidator that Pedro suggests? We felt that the federation might come from the fact that we wanted GDB to be smart enough to create new breakpoint locations when re-evaluating breakpoints, for instance if a shared library got mapped and caused new locations to match. That's where Jerome's suggestion of treating "all" breakpoints as dynamic (vs treating specific-instance breakpoints as static) comes into play. If the user uses an umbiguous linespec, and then selects "all" (either automatically via multiple-symbol, or manually via the multiple-choice menu), then create a dynamic version of the breakpoint, which will constantly re-evaluate its locations. Otherwise, create a series of static breakpoints, whose source location are well enough defined to be unique. There is a form of canonical linespec that we have been using at AdaCore, which we think could be used universally: FILE:FUNCTION:LINE The FUNCTION name is the fully qualified name. For Ada, it means for instance: foo.adb:pck.gen.func:8 In C++ (bare in mind that we don't know much about C++ debugging), it could be something like this: foo.cc:GetMax(int):8 But now, Jerome just whispered in my ears that using a multiple-location breakpoint for homonyms would not work well in the following case: Imagine ther user is trying to put a condition on a breakpoint that has locations in units of different languages. What language would we use? Right now, he says that, for lang auto, we do the nice thing of using the unit's language to evaluate the condition. So, in the end, it seems difficult to imagine that one single breakpoint could have multiple slocs. And it also seems that the suggestion of treating "all" breakpoints as multiple-location breakpoints would suffer from the same problem. So, perhaps the 3rd-tier linespec-based breakpoint might make sense, after all... If we were to go that route, I'm just worried about the potential for confusing the user, with 3 levels of breakpoints, and I'm wondering if this could be helped... Perhaps we could hide the intermediate level, and just show the top and bottom levels to the user (I'm thinking of breakpoint notifications as well as the output of "info break"). In terms of implementation, if we were to decide on a 3rd-tier linespec-based breakpoint, I'd rather have it all the time, even for non-ambiguous breakpoints (which might become ambiguous later, as Tom points out). Even if a bit wasteful, I think it's easier to deal with, rather than having a polymorphic list of breakpoints... I still maintain, however, that it's important to be able to break on a selected subset of locations via the multiple-choice menu. We've had some users who immediately asked about this as soon as we switched the default to breaking on all matching locations. -- Joel