From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9863 invoked by alias); 29 Jan 2008 22:17:57 -0000 Received: (qmail 9825 invoked by uid 22791); 29 Jan 2008 22:17:55 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 29 Jan 2008 22:17:36 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 5A0B498151 for ; Tue, 29 Jan 2008 22:17:34 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id F2D569811F for ; Tue, 29 Jan 2008 22:17:33 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.68) (envelope-from ) id 1JJylp-0001hh-31 for gdb-patches@sourceware.org; Tue, 29 Jan 2008 17:17:33 -0500 Date: Tue, 29 Jan 2008 22:34:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sourceware.org Subject: Re: [RFA/dwarf] save nested Ada subprograms as global symbol Message-ID: <20080129221733.GI15063@caradoc.them.org> Mail-Followup-To: gdb-patches@sourceware.org References: <20071227073938.GC10767@adacore.com> <20080129171610.GE2815@caradoc.them.org> <20080129214501.GF16288@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080129214501.GF16288@adacore.com> User-Agent: Mutt/1.5.17 (2007-12-11) 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: 2008-01/txt/msg00735.txt.bz2 On Tue, Jan 29, 2008 at 01:45:01PM -0800, Joel Brobecker wrote: > For Ada, the debugger takes the stand that there is an implicit > "use" of all compilation units. The GDB manual documents this: > > Thus, for brevity, the debugger acts as if there were implicit with > and use clauses in effect for all user-written packages, making it > unnecessary to fully qualify most names with their packages, > regardless of context. Where this causes ambiguity, GDB asks the > user's intent. > > In the case of Hello.First and Goodbye.First, the user should expect > that a breakpoint should be inserted in each function. If the user > wants to specifically break on say Hello.First, then he should use > its fully qualified name. "for all user-written packages"; functions aren't packages, are they? > > A related example in C++ would be: > > > > namespace A { > > void first () { } > > > > void second () { first (); } > > } > > > > int main() > > { > > A::second (); > > } > > > > GDB will not honor "break first" when stopped in main. But in second, > > when the listed source line says "first ();", "break first" will work. > > David Carlton did a lot of work to make this happen; the hook it uses > > is cp_lookup_symbol_nonlocal. In practice, it seems to be the > > behavior users expect. > > To me, this makes the debugger unnecessarily harder to use. Why force > the user to be inside a specific location before he can break on > a function? Especially since the breakpoint will remain valid > even after leaving the function's scope. You don't have to be in second to break on first - sorry if that was unclear. You have to be in second for "break first" to work. "break A::first" always works. > If I were to draw a parallel with our experience in Ada, we have > found that the debugger is more useful when we allow the user to > break on "first" from wherever. If the user wants to break on > the specific function A::first, couldn't he use "break A::first" > (not tried)? Sure. If I put a breakpoint on "search" from my application and GDB also stopped at "std::search" instantiated from the Standard Template Library, I'd be very surprised. I said "search", not "std::search", and GDB knows where to look for something named "search"; if you haven't said "using std", it shouldn't search std. But this is a fairly clear difference between the expectations of C++ and Ada developers. A closer analogy to nested procedures may be class methods. Are the names of functions in packages normally relatively unique? How about for nested functions? In C++, names within namespaces are relatively unique, and method names are not ("next", "iterator", etc.). Anyway, I'm certainly willing to follow your lead on what Ada users expect. I'm wondering if I'm barking at the wrong part of your message, though. Does the symbol for the nested subprogram end up with an unqualified name (e.g., "first") in the global symbol table? IMO the symbol table should reflect the program structure. -- Daniel Jacobowitz CodeSourcery