From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21625 invoked by alias); 29 Jan 2008 21:45:24 -0000 Received: (qmail 21613 invoked by uid 22791); 29 Jan 2008 21:45:22 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 29 Jan 2008 21:45:05 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id C1CA22A96C4 for ; Tue, 29 Jan 2008 16:45:03 -0500 (EST) 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 cGxGMNkhTUga for ; Tue, 29 Jan 2008 16:45:03 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 63BDC2A96C1 for ; Tue, 29 Jan 2008 16:45:03 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 3779DE7ACB; Tue, 29 Jan 2008 13:45:01 -0800 (PST) Date: Tue, 29 Jan 2008 21:45:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org Subject: Re: [RFA/dwarf] save nested Ada subprograms as global symbol Message-ID: <20080129214501.GF16288@adacore.com> References: <20071227073938.GC10767@adacore.com> <20080129171610.GE2815@caradoc.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080129171610.GE2815@caradoc.them.org> User-Agent: Mutt/1.4.2.2i 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/msg00729.txt.bz2 > Sorry, I really don't like this idea. What if you have a hello.first > and a goodbye.first? They're not related, so a breakpoint on "first" > landing in both spots would be strange. It wouldn't be strange to an Ada user. I need to introduce the notion of qualified versus unqualified name. In Ada, the name of an entity is always qualified. For instance, if a function Foo is declared inside package Bar, then its qualified name is Bar.Foo. Normally, when you write programs in Ada, you are always supposed to reference other entities using their qualified name. For instance, given the following package: package Pck is procedure Do_Nothing; end Pck; If you want to use that procedure from elsewhere, you have to write: with Pck; -- Tells the compiler that you're using unit Pck; procedure Foo is begin Pck.Do_Nothing; end Foo; If you said "Do_Nothing;" without the "Pck.", then the compiler would complain that this entity is not visible and abort: % gcc -c -g foo.adb foo.adb:5:04: "Do_Nothing" is not visible foo.adb:5:04: non-visible declaration at pck.ads:2 Realizing that this can quickly become a pain, the language allows you to access directly the entities from a given package using the unqualified name, provided you explicitly request it (with a "use" clause"): with Pck; use Pck; procedure Foo is begin Do_Nothing; end Foo; 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. > 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. 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)? Does the above context information change your position, or do you still think the Ada behavior is strange? -- Joel