From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2658 invoked by alias); 30 Jan 2008 20:42:40 -0000 Received: (qmail 2512 invoked by uid 22791); 30 Jan 2008 20:42:38 -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; Wed, 30 Jan 2008 20:42:12 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 76AD898214 for ; Wed, 30 Jan 2008 20:42:10 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 4EDA79801D for ; Wed, 30 Jan 2008 20:42:10 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.68) (envelope-from ) id 1JKJl2-000138-Te for gdb-patches@sourceware.org; Wed, 30 Jan 2008 15:42:08 -0500 Date: Wed, 30 Jan 2008 21:03:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sourceware.org Subject: Re: [RFA/dwarf] save nested Ada subprograms as global symbol Message-ID: <20080130204208.GA3659@caradoc.them.org> Mail-Followup-To: gdb-patches@sourceware.org References: <20071227073938.GC10767@adacore.com> <20080129171610.GE2815@caradoc.them.org> <20080129214501.GF16288@adacore.com> <20080129221733.GI15063@caradoc.them.org> <20080130202816.GD12387@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080130202816.GD12387@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/msg00827.txt.bz2 On Wed, Jan 30, 2008 at 12:28:16PM -0800, Joel Brobecker wrote: > > 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. > > Do I have to be inside namespace A, you mean? Right. Or something which uses namespace A. > I'm also realizing that the habits of C++ and Ada developers seem pretty > different in some ways. I think that part of it is because of differences > in the language. In Ada, if you "use" a package, then you no longer need > to specify the scopy when you refer to an entity. So it's very common > to see a call to a function using its unqualified name, and the resolution > of that name is not just dependent on the scope where it's used, it's > also dependent on what "use" clauses have been defined. I don't know > that this is possible in C++. I'm assuming that "search" from inside > std means "std::search", but that "search" from any other context can > never mean "std::search", hence the surprise factor in C++. There's a "using" directive for this; from a language level, the situation is the same as in Ada. But I don't know how often it is or isn't used. > > 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.). > > If I simplify a bit how the linkage name of any entity is generated, > the process is fairly simple. The name of an entity is prefixed by > the name of the context followed by "__" followed by the name of the > entity in lowercase. For instance: > > package body Pck is > procedure Do_Nothing is > procedure First is null procedure; > begin > Pck.Do_Nothing.First; > end Do_Nothing; > end Pck; > > The linkage name of Pck.Do_Nothing is "pck__do_nothing". Similarly, > the linkage name of Pck.Do_Nothing.First is "pck__do_nothing__first". I meant the unqualified names. Are you likely to have a dozen different procedures in your program, all containing a nested method named "first"? This happens, but relatively uncommonly, with namespaces. It happens all the time with methods. > > 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? > > The symbol name for the nested subprogram is qualified. Oh. Well, that's much less reason to object then. I thought you were putting "first" into the symbol table, but "pck.do_nothing.first" and then finding that on searches for "first" bothers me much less. > > IMO the symbol table should reflect the program structure. > > You mean that the symbol should be stored in the scope where > the function is defined? (which is what my patch is UNdoing). > > I would tend to agree. The goal is to make it easy for the user to use > the debugger, and I think that being able to break on nested subprograms > without having to specify the scope is an important feature. I certainly > have been relying on it quite a bit. The problem is on how to implement > this feature. The approach I chose was to make the symbol global > instead of nested. Pretty quick and effective - I'm still unsure of > the consequences at the user-level of this approach. Another way we could > do would be to expand the symbol search routine to look inside functions > for nested functions. But I'm concerned about the peformance aspect of > this. What do you think? If you want to be able to use the name unqualified, then the global symbol table sounds like the right place to put it. I'd like namespace members and procedures containing nested functions to be hierarchical elements in the symbol table, but that's not how it works today. I'd suggest we do the same for nested C functions but it would be a horrible mess; they don't have conveniently mangled or qualified names. -- Daniel Jacobowitz CodeSourcery