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

[Daniel Jacobowitz <drow at false dot org>]

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<Iter1, Iter2, Equals>" 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