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

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

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 2694 bytes --]

Hello,

This is part of what I hope will be a string of patches that should
bring the GDB close to the AdaCore version of GDB in terms of Ada support.
My hope is to find the time this year to reach that level, which
would then make it easier for us to keep Ada support between our tree
and the FSF tree synchronized.

The Ada language provides support for nested subprograms. Consider
the following simple program:

        procedure Hello is
        
           procedure First is
           begin
              null;
           end First;
        
           procedure Second is
           begin
              First;
           end Second;
        
           procedure Third is
           begin
              Second;
           end Third;
        
        begin
           Third;
        end Hello;

This is a trivial program, where the main procedure (Hello) contains
three nested procedures (Third, Second, and First). To compile it,
do the following:

        % gnatmake -g hello

The problem is trying to break on First:

        % gdb hello
        (gdb) break first
        Function "first" not defined.
        Make breakpoint pending on future shared library load? (y or [n]) n

What we'd like to be able to do is:

        (gdb) b first
        Breakpoint 1 at 0x804954a: file hello.adb, line 6.
        (gdb) run
        Starting program: /home/no-backup/brobecke/ada-fsf/nested/hello 
        
        Breakpoint 1, hello.first () at hello.adb:6
        6          end First;

To achieve this, we modified dwarf2read to store all Ada subprograms
in the global scope, even the ones that are not "external". Another
approach that was considered was to modify the Ada lookup routines
to extend the search to non-global/static scopes, but I'm concerned
about performance.

In practice, even though these routines are indeed local to our
procedure in the Ada program, we want to be flexible with the user
in the debugger, and treat these procedures as global, so that the
user can break inside them without specifying the scope or having
to be in the scope where the function is defined.

This is what the attached patch does:

2007-12-27  Joel Brobecker  <brobecker@adacore.com>

        * dwarf2read.c (add_partial_symbol): Always store all Ada subprograms
        in the global scope.
        (new_symbol): Likewise.

Tested on x86-linux, no regression.  OK to commit?

I am also attaching a testcase that fails without this patch:

2007-12-27  Joel Brobecker  <brobecker@adacore.com>

        * gdb.ada/nested/hello.adb: New file.
        * gdb.ada/nested.exp: New testcase.
        * gdb.ada/Makefile.in (EXECUTABLES): Update list.

Tested on x86-linux as well.

Thanks,
-- 
Joel

[-- Attachment #2: TAG_subprogram.diff --]
[-- Type: text/plain, Size: 1733 bytes --]

Index: dwarf2read.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2read.c,v
retrieving revision 1.243
diff -u -p -r1.243 dwarf2read.c
--- dwarf2read.c	22 Dec 2007 20:58:30 -0000	1.243
+++ dwarf2read.c	27 Dec 2007 05:46:35 -0000
@@ -1898,8 +1898,12 @@ add_partial_symbol (struct partial_die_i
   switch (pdi->tag)
     {
     case DW_TAG_subprogram:
-      if (pdi->is_external)
+      if (pdi->is_external || cu->language == language_ada)
 	{
+          /* brobecker/2007-12-26: Normally, only "external" DIEs are part
+             of the global scope.  But in Ada, we want to be able to access
+             nested procedures globally.  So all Ada subprograms are stored
+             in the global scope.  */
 	  /*prim_record_minimal_symbol (actual_name, pdi->lowpc + baseaddr,
 	     mst_text, objfile); */
 	  psym = add_psymbol_to_list (actual_name, strlen (actual_name),
@@ -7288,8 +7292,15 @@ new_symbol (struct die_info *die, struct
 	     finish_block.  */
 	  SYMBOL_CLASS (sym) = LOC_BLOCK;
 	  attr2 = dwarf2_attr (die, DW_AT_external, cu);
-	  if (attr2 && (DW_UNSND (attr2) != 0))
+	  if ((attr2 && (DW_UNSND (attr2) != 0))
+              || cu->language == language_ada)
 	    {
+              /* Subprograms marked external are stored as a global symbol.
+                 Ada subprograms, whether marked external or not, are always
+                 stored as a global symbol, because we want to be able to
+                 access them globally.  For instance, we want to be able
+                 to break on a nested subprogram without having to
+                 specify the context.  */
 	      add_symbol_to_list (sym, &global_symbols);
 	    }
 	  else

[-- Attachment #3: hello.adb --]
[-- Type: text/plain, Size: 937 bytes --]

--  Copyright 2007 Free Software Foundation, Inc.
--
--  This program is free software; you can redistribute it and/or modify
--  it under the terms of the GNU General Public License as published by
--  the Free Software Foundation; either version 3 of the License, or
--  (at your option) any later version.
--
--  This program is distributed in the hope that it will be useful,
--  but WITHOUT ANY WARRANTY; without even the implied warranty of
--  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
--  GNU General Public License for more details.
--
--  You should have received a copy of the GNU General Public License
--  along with this program.  If not, see <http://www.gnu.org/licenses/>.

procedure Hello is

   procedure First is
   begin
      null;
   end First;

   procedure Second is
   begin
      First;
   end Second;

   procedure Third is
   begin
      Second;
   end Third;

begin
   Third;
end Hello;


[-- Attachment #4: nested.exp --]
[-- Type: text/plain, Size: 1355 bytes --]

# Copyright 2007 Free Software Foundation, Inc.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see <http://www.gnu.org/licenses/>.

if $tracelevel then {
    strace $tracelevel
}

load_lib "ada.exp"

set testdir "nested"
set testfile "${testdir}/hello"
set srcfile ${srcdir}/${subdir}/${testfile}.adb
set binfile ${objdir}/${subdir}/${testfile}

file mkdir ${objdir}/${subdir}/${testdir}
if {[gdb_compile_ada "${srcfile}" "${binfile}" executable [list debug ]] != "" } {
  return -1
}

gdb_exit
gdb_start
gdb_reinitialize_dir $srcdir/$subdir
gdb_load ${binfile}

set any_nb "\[0-9\]+"
set any_addr "0x\[0-9a-zA-Z\]+"

# Try breaking on a nested function.

gdb_test "break first" \
         "Breakpoint $any_nb at $any_addr: file .*hello.adb, line $any_nb." \
         "break on nested function First"


[-- Attachment #5: gdb.ada-makefile.in.diff --]
[-- Type: text/plain, Size: 512 bytes --]

Index: gdb.ada/Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.ada/Makefile.in,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile.in
--- gdb.ada/Makefile.in	26 Dec 2007 14:21:53 -0000	1.3
+++ gdb.ada/Makefile.in	27 Dec 2007 07:37:36 -0000
@@ -11,6 +11,7 @@ EXECUTABLES = \
   exec_changed/second \
   fixed_points/fixed_points \
   frame_args/foo \
+  nested/hello \
   null_record/null_record \
   packed_array/pa \
   print_chars/foo \

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

[Daniel Jacobowitz]

On Wed, Dec 26, 2007 at 11:39:38PM -0800, Joel Brobecker wrote:
> The problem is trying to break on First:
> 
>         % gdb hello
>         (gdb) break first
>         Function "first" not defined.
>         Make breakpoint pending on future shared library load? (y or [n]) n
> 
> What we'd like to be able to do is:
> 
>         (gdb) b first
>         Breakpoint 1 at 0x804954a: file hello.adb, line 6.
>         (gdb) run
>         Starting program: /home/no-backup/brobecke/ada-fsf/nested/hello 
>         
>         Breakpoint 1, hello.first () at hello.adb:6
>         6          end First;
> 
> To achieve this, we modified dwarf2read to store all Ada subprograms
> in the global scope, even the ones that are not "external". Another
> approach that was considered was to modify the Ada lookup routines
> to extend the search to non-global/static scopes, but I'm concerned
> about performance.
> 
> In practice, even though these routines are indeed local to our
> procedure in the Ada program, we want to be flexible with the user
> in the debugger, and treat these procedures as global, so that the
> user can break inside them without specifying the scope or having
> to be in the scope where the function is defined.

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.

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.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Joel Brobecker]

> 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

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

[Daniel Jacobowitz]

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

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

[Joel Brobecker]

> >     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?

Hmm, yes, you are right. I'm stretching the documented behavior.
Functions are not packages, but it seemed natural to treat them
as such for symbol name resolution: The full name is Goodbye.First,
and "First" should match too. So if we modify the debugger, I'll have
to remember to update the documentation as well.

> > > A related example in C++ would be:
> > > 
> > > namespace A {
> > >   void first () { }
> > > 
> > >   void second () { first (); }
> > > }
> > > 
> > > int main()
> > > {
> > >   A::second ();
> > > }
> 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?

> "break A::first" always works.

That's good to hear. Similarly, "break Goodbye.First" should work too,
IMO, but for some reason, it doesn't. It works with AdaCore's version,
though. I guess it's so uncommon for me to be using the fully qualified
name that I've never thought of having a test that verifies this.
I will leave that specific problem for another day.

> 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.

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++.

> 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".

> 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.

> 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?

-- 
Joel

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

[Daniel Jacobowitz]

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

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

[Joel Brobecker]

> > > 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.).
[...]
> I meant the unqualified names.  Are you likely to have a dozen
> different procedures in your program, all containing a nested method
> named "first"?

It's hard to tell. I would guess that nested subprograms are not
different in terms of naming from regular non-nested subprograms.

> 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.

Ah, yes, I understand now where you are coming from. This is my fault,
I should have been more complete in my first message. Sometimes,
I overlook significant details that are obvious to me, but actually
not obvious to someone not familiar with the GNAT compiler...

> 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.

So is the original patch OK, then?

> 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.

For purely-C nested functions, doesn't it work already? Actually,
I just gave it a try and I was able to break on my nested procedure.
Given:

    int
    main (void)
    {
       void do_nothing (void) {};
    
       do_nothing ();
       return 0;
    }

I was able to break on "do_nothing" and run to it:

    (gdb) b do_nothing
    Breakpoint 1 at 0x8048355: file foo.c, line 5.
    (gdb) run
    Starting program: /[...]/foo 
    
    Breakpoint 1, do_nothing () at foo.c:5
    5          void do_nothing (void) {};

-- 
Joel

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

[Daniel Jacobowitz]

On Wed, Jan 30, 2008 at 02:58:33PM -0800, Joel Brobecker wrote:
> > 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.
> 
> So is the original patch OK, then?

Yes.

> > 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.
> 
> For purely-C nested functions, doesn't it work already? Actually,
> I just gave it a try and I was able to break on my nested procedure.
> Given:
> 
>     int
>     main (void)
>     {
>        void do_nothing (void) {};
>     
>        do_nothing ();
>        return 0;
>     }

This works because GCC 4 is very aggressive about un-nesting :-)  Try
something that would require a static chain, e.g. because it accesses
the container's locals.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Joel Brobecker]

> 2007-12-27  Joel Brobecker  <brobecker@adacore.com>
> 
>         * dwarf2read.c (add_partial_symbol): Always store all Ada subprograms
>         in the global scope.
>         (new_symbol): Likewise.
> 
> Tested on x86-linux, no regression.  OK to commit?
> 
> I am also attaching a testcase that fails without this patch:
> 
> 2007-12-27  Joel Brobecker  <brobecker@adacore.com>
> 
>         * gdb.ada/nested/hello.adb: New file.
>         * gdb.ada/nested.exp: New testcase.
>         * gdb.ada/Makefile.in (EXECUTABLES): Update list.

Just to confirm that this one has now been checked in.
(thanks, Daniel)

-- 
Joel