Re: [RFA/dwarf] save nested Ada subprograms as global symbol

[Daniel Jacobowitz <drow at false dot org>]

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