This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]