adding namespace support to GDB

adding namespace support to GDB

[David Carlton]

I recently asked Daniel Jacobwitz for suggestions as to what I could
do to help GDB, and he suggested that I might try adding proper
namespace support.  I've skimmed a thread on the issue from early
April with lots of interesting ideas; at some point, it sounded like
Jim Blandy was about to start writing up some concrete possible
interfaces, and I was wondering if anything more came of that.

For the time being, I'm going to reread that thread more closely, look
at Petr Sorfa's module patch, look at the DWARF-3 standard, look at
existing GDB code, and think about this for a while.  (Or at least I
hope that's what I'm going to do: maybe I'll instead spend all of my
time arguing with Stanford's benefits office.  Anybody know of any
interesting free software jobs in countries with nationalized health
insurance?)  But I don't want to duplicate effort if somebody else has
already started working on this.

David Carlton
carlton@math.stanford.edu

Re: adding namespace support to GDB

[Petr Sorfa]

Hi David,

Well to help things along I will be submitting a DWARF patch that will
supported imported declarations which are essential for FORTRAN modules
and C++ namespaces. This is essential for the "using" commands in either
language (of course the compiler needs to generate the correct DWARF
;o)).

I'm making some changes to my TAG_module patch which hopefully will get
it accepted.

C++ namespaces are fairly similar to FORTRAN modules, except FORTRAN95
seems to have a more powerful "using" command (ability to rename
imported symbols), and C++ a more flexible use of namespaces.

Both the patches for modules and imported declarations will be submitted
early next week.

Petr
> I recently asked Daniel Jacobwitz for suggestions as to what I could
> do to help GDB, and he suggested that I might try adding proper
> namespace support.  I've skimmed a thread on the issue from early
> April with lots of interesting ideas; at some point, it sounded like
> Jim Blandy was about to start writing up some concrete possible
> interfaces, and I was wondering if anything more came of that.
> 
> For the time being, I'm going to reread that thread more closely, look
> at Petr Sorfa's module patch, look at the DWARF-3 standard, look at
> existing GDB code, and think about this for a while.  (Or at least I
> hope that's what I'm going to do: maybe I'll instead spend all of my
> time arguing with Stanford's benefits office.  Anybody know of any
> interesting free software jobs in countries with nationalized health
> insurance?)  But I don't want to duplicate effort if somebody else has
> already started working on this.
> 
> David Carlton
> carlton@math.stanford.edu

Re: adding namespace support to GDB

[David Carlton]

In article <3D6677D3.6E84743C@caldera.com>, Petr Sorfa
<petrs@caldera.com> writes:

> Well to help things along I will be submitting a DWARF patch that
> will supported imported declarations which are essential for FORTRAN
> modules and C++ namespaces.

Great, I look forward to reading it.

> This is essential for the "using" commands in either language (of
> course the compiler needs to generate the correct DWARF
> ;o)).

Yes, well, there is always that.  Certainly it seems like a solution
for C++ will initially have to get recreate namespace info from
DW_AT_MIPS_linkage_name, and there's no way that we'll be able to
allow users to use symbol names as if all the appropriate using
directives were in effect, since that information simply isn't in the
debug information that GCC is currently producing.  (Though that's not
the end of the world: we should be able to do name lookup using C++'s
name resolution rules based on the enclosing function and its
arguments, presumably.)

David Carlton
carlton@math.stanford.edu

Re: adding namespace support to GDB

[Daniel Berlin]

On 23 Aug 2002, David Carlton wrote:

> In article <3D6677D3.6E84743C@caldera.com>, Petr Sorfa
> <petrs@caldera.com> writes:
> 
> > Well to help things along I will be submitting a DWARF patch that
> > will supported imported declarations which are essential for FORTRAN
> > modules and C++ namespaces.
> 
> Great, I look forward to reading it.
> 
> > This is essential for the "using" commands in either language (of
> > course the compiler needs to generate the correct DWARF
> > ;o)).
> 
> Yes, well, there is always that.

This is easy, i've had patches to do it forever, that are already 
approved.
I'm just waiting for gdb to get around to namespace support before 
committing them, because it turns out we don't want to add a -gdwarf-3 
switch.
 >  Certainly it seems like a solution
> for C++ will initially have to get recreate namespace info from
> DW_AT_MIPS_linkage_name, and there's no way that we'll be able to
> allow users to use symbol names as if all the appropriate using
> directives were in effect, since that information simply isn't in the
> debug information that GCC is currently producing.  (Though that's not
> the end of the world: we should be able to do name lookup using C++'s
> name resolution rules based on the enclosing function and its
> arguments, presumably.)
> 
> David Carlton
> carlton@math.stanford.edu
> 
> 

Re: adding namespace support to GDB

[Petr Sorfa]

Hi Daniel,

Well, let me or John Wolfe submit a patch with the imported declaration
support next week. It will at least be some kind of comparison.

Petr
> > In article <3D6677D3.6E84743C@caldera.com>, Petr Sorfa
> > <petrs@caldera.com> writes:
> >
> > > Well to help things along I will be submitting a DWARF patch that
> > > will supported imported declarations which are essential for FORTRAN
> > > modules and C++ namespaces.
> >
> > Great, I look forward to reading it.
> >
> > > This is essential for the "using" commands in either language (of
> > > course the compiler needs to generate the correct DWARF
> > > ;o)).
> >
> > Yes, well, there is always that.
> 
> This is easy, i've had patches to do it forever, that are already
> approved.
> I'm just waiting for gdb to get around to namespace support before
> committing them, because it turns out we don't want to add a -gdwarf-3
> switch.
>  >  Certainly it seems like a solution
> > for C++ will initially have to get recreate namespace info from
> > DW_AT_MIPS_linkage_name, and there's no way that we'll be able to
> > allow users to use symbol names as if all the appropriate using
> > directives were in effect, since that information simply isn't in the
> > debug information that GCC is currently producing.  (Though that's not
> > the end of the world: we should be able to do name lookup using C++'s
> > name resolution rules based on the enclosing function and its
> > arguments, presumably.)
> >
> > David Carlton
> > carlton@math.stanford.edu
> >
> >

Re: adding namespace support to GDB

[Daniel Berlin]

On Fri, 23 Aug 2002, Petr Sorfa wrote:

> Hi Daniel,
> 
> Well, let me or John Wolfe submit a patch with the imported declaration
> support next week. It will at least be some kind of comparison.

My gcc patch already includes this.

I've rediffed against current gcc sources, and pasted it below.

Index: dwarf2out.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/dwarf2out.c,v
retrieving revision 1.379.2.3
diff -c -3 -p -w -B -b -r1.379.2.3 dwarf2out.c
*** dwarf2out.c	19 Aug 2002 01:30:33 -0000	1.379.2.3
--- dwarf2out.c	23 Aug 2002 22:33:11 -0000
*************** static void gen_tagged_type_instantiatio
*** 3648,3654 ****
--- 3648,3656 ----
  static void gen_block_die		PARAMS ((tree, dw_die_ref, int));
  static void decls_for_scope		PARAMS ((tree, dw_die_ref, int));
  static int is_redundant_typedef		PARAMS ((tree));
+ static void gen_namespace_die           PARAMS ((tree, dw_die_ref));
  static void gen_decl_die		PARAMS ((tree, dw_die_ref));
+ static dw_die_ref force_out_decl	PARAMS ((tree, dw_die_ref));
  static unsigned lookup_filename		PARAMS ((const char *));
  static void init_file_table		PARAMS ((void));
  static void retry_incomplete_types	PARAMS ((void));
*************** dwarf_tag_name (tag)
*** 3905,3910 ****
--- 3907,3914 ----
        return "DW_TAG_namelist";
      case DW_TAG_namelist_item:
        return "DW_TAG_namelist_item";
+     case DW_TAG_namespace:
+       return "DW_TAG_namespace";
      case DW_TAG_packed_type:
        return "DW_TAG_packed_type";
      case DW_TAG_subprogram:
*************** scope_die_for (t, context_die)
*** 9540,9548 ****
  
    containing_scope = TYPE_CONTEXT (t);
  
!   /* Ignore namespaces for the moment.  */
    if (containing_scope && TREE_CODE (containing_scope) == NAMESPACE_DECL)
!     containing_scope = NULL_TREE;
  
    /* Ignore function type "scopes" from the C frontend.  They mean that
       a tagged type is local to a parmlist of a function declarator, but
--- 9544,9563 ----
  
    containing_scope = TYPE_CONTEXT (t);
  
!   /* Handle namespaces properly */
    if (containing_scope && TREE_CODE (containing_scope) == NAMESPACE_DECL)
!     {
!       dw_die_ref newcontext = lookup_decl_die (containing_scope);
! 
!       if (!newcontext)
! 	{
! 	  gen_decl_die (containing_scope, context_die);
! 	  newcontext = lookup_decl_die (containing_scope);
! 	  if (!newcontext)
! 	    abort();
! 	}
!       context_die = newcontext;
!     }
  
    /* Ignore function type "scopes" from the C frontend.  They mean that
       a tagged type is local to a parmlist of a function declarator, but
*************** is_redundant_typedef (decl)
*** 11374,11379 ****
--- 11389,11453 ----
  
    return 0;
  }
+ static dw_die_ref
+ force_out_decl (decl, context_die)
+ 	tree decl;
+ 	dw_die_ref context_die;
+ {
+   /* Force out the namespace. */
+   if (DECL_CONTEXT (decl) && TREE_CODE (DECL_CONTEXT (decl)) == NAMESPACE_DECL)
+     {
+       dw_die_ref newcontext;
+       newcontext = lookup_decl_die (DECL_CONTEXT (decl));
+       if (!newcontext)
+ 	{
+ 	  gen_decl_die (DECL_CONTEXT (decl), context_die);
+ 	  newcontext = lookup_decl_die (DECL_CONTEXT (decl));
+ 	  if (!newcontext)
+ 	    abort();
+ 	}
+       context_die = newcontext;
+     }
+   return context_die;
+ }
+ 
+ /* Generate a DIE for a namespace or namespace alias */
+ static void
+ gen_namespace_die (decl, context_die)
+      register tree decl;
+      register dw_die_ref context_die;
+ {
+   /* Namespace aliases have a DECL_ABSTRACT_ORIGIN of the namespace
+      they are an alias of.*/
+   if (DECL_ABSTRACT_ORIGIN (decl) == NULL)
+     {
+       /* Output a real namespace */
+       dw_die_ref namespace_die = new_die (DW_TAG_namespace, context_die, decl);
+       add_name_and_src_coords_attributes (namespace_die, decl);
+       equate_decl_number_to_die (decl, namespace_die);
+     }
+   else
+     {
+       /* Output a namespace alias */
+       dw_die_ref namespace_die;
+       
+       /* Force out the namespace we are an alias of, if necessary */
+       dw_die_ref origin_die = lookup_decl_die  (DECL_ABSTRACT_ORIGIN (decl));
+       if (!origin_die)
+ 	{
+ 	  /* Attempt to force out origin. */
+ 	  dwarf2out_decl (DECL_ABSTRACT_ORIGIN (decl));
+ 	  origin_die = lookup_decl_die (DECL_ABSTRACT_ORIGIN (decl));
+ 	  if (!origin_die)
+ 	    abort();
+ 	}
+       /* Now create the namespace alias DIE. */
+       namespace_die = new_die (DW_TAG_imported_declaration, context_die, decl);
+       add_name_and_src_coords_attributes (namespace_die, decl);
+       add_AT_die_ref (namespace_die, DW_AT_import, origin_die);
+       equate_decl_number_to_die (decl, namespace_die);
+     }
+ }
  
  /* Generate Dwarf debug information for a decl described by DECL.  */
  
*************** gen_decl_die (decl, context_die)
*** 11424,11429 ****
--- 11498,11505 ----
        /* Otherwise we're emitting the primary DIE for this decl.  */
        else if (debug_info_level > DINFO_LEVEL_TERSE)
  	{
+ 	  context_die = force_out_decl (decl, context_die);
+ 
  	  /* Before we describe the FUNCTION_DECL itself, make sure that we
  	     have described its return type.  */
  	  gen_type_die (TREE_TYPE (TREE_TYPE (decl)), context_die);
*************** gen_decl_die (decl, context_die)
*** 11447,11453 ****
           actual typedefs.  */
        if (debug_info_level <= DINFO_LEVEL_TERSE)
  	break;
! 
        /* In the special case of a TYPE_DECL node representing the declaration
           of some type tag, if the given TYPE_DECL is marked as having been
           instantiated from some other (original) TYPE_DECL node (e.g. one which
--- 11523,11529 ----
           actual typedefs.  */
        if (debug_info_level <= DINFO_LEVEL_TERSE)
  	break;
!       context_die = force_out_decl (decl, context_die);
        /* In the special case of a TYPE_DECL node representing the declaration
           of some type tag, if the given TYPE_DECL is marked as having been
           instantiated from some other (original) TYPE_DECL node (e.g. one which
*************** gen_decl_die (decl, context_die)
*** 11477,11482 ****
--- 11553,11559 ----
           variable declarations or definitions.  */
        if (debug_info_level <= DINFO_LEVEL_TERSE)
  	break;
+       context_die = force_out_decl (decl, context_die);
  
        /* Output any DIEs that are needed to specify the type of this data
           object.  */
*************** gen_decl_die (decl, context_die)
*** 11504,11509 ****
--- 11581,11587 ----
        if (DECL_NAME (decl) != NULL_TREE
  	  || TREE_CODE (TREE_TYPE (decl)) == UNION_TYPE)
  	{
+ 	  context_die = force_out_decl (decl, context_die);
  	  gen_type_die (member_declared_type (decl), context_die);
  	  gen_field_die (decl, context_die);
  	}
*************** gen_decl_die (decl, context_die)
*** 11515,11521 ****
        break;
  
      case NAMESPACE_DECL:
!       /* Ignore for now.  */
        break;
  
      default:
--- 11593,11600 ----
        break;
  
      case NAMESPACE_DECL:
!       context_die = force_out_decl (decl, context_die);
!       gen_namespace_die (decl, context_die);
        break;
  
      default:
*************** dwarf2out_decl (decl)
*** 11668,11673 ****
--- 11747,11759 ----
  
        /* If we are in terse mode, don't generate any DIEs for types.  */
        if (debug_info_level <= DINFO_LEVEL_TERSE)
+     case NAMESPACE_DECL:
+       if (debug_info_level <= DINFO_LEVEL_TERSE)
+ 	return;
+       if (lookup_decl_die (decl) != NULL)
+         return;
+       break;
+       
  	return;
  
        /* If we're a function-scope tag, initially use a parent of NULL;

Re: adding namespace support to GDB

[Petr Sorfa]

Hi Daniel,

I'm confused. This patch is against gcc not gdb. I meant that the patch
we will submit will be for gdb support of imported declarations.

Petr
> On Fri, 23 Aug 2002, Petr Sorfa wrote:
> 
> > Hi Daniel,
> >
> > Well, let me or John Wolfe submit a patch with the imported declaration
> > support next week. It will at least be some kind of comparison.
> 
> My gcc patch already includes this.
> 
> I've rediffed against current gcc sources, and pasted it below.
> 
> Index: dwarf2out.c
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/dwarf2out.c,v
> retrieving revision 1.379.2.3
> diff -c -3 -p -w -B -b -r1.379.2.3 dwarf2out.c
> *** dwarf2out.c 19 Aug 2002 01:30:33 -0000      1.379.2.3
> --- dwarf2out.c 23 Aug 2002 22:33:11 -0000
> *************** static void gen_tagged_type_instantiatio
> *** 3648,3654 ****
> --- 3648,3656 ----
>   static void gen_block_die             PARAMS ((tree, dw_die_ref, int));
>   static void decls_for_scope           PARAMS ((tree, dw_die_ref, int));
>   static int is_redundant_typedef               PARAMS ((tree));
> + static void gen_namespace_die           PARAMS ((tree, dw_die_ref));
>   static void gen_decl_die              PARAMS ((tree, dw_die_ref));
> + static dw_die_ref force_out_decl      PARAMS ((tree, dw_die_ref));
>   static unsigned lookup_filename               PARAMS ((const char *));
>   static void init_file_table           PARAMS ((void));
>   static void retry_incomplete_types    PARAMS ((void));
> *************** dwarf_tag_name (tag)
> *** 3905,3910 ****
> --- 3907,3914 ----
>         return "DW_TAG_namelist";
>       case DW_TAG_namelist_item:
>         return "DW_TAG_namelist_item";
> +     case DW_TAG_namespace:
> +       return "DW_TAG_namespace";
>       case DW_TAG_packed_type:
>         return "DW_TAG_packed_type";
>       case DW_TAG_subprogram:
> *************** scope_die_for (t, context_die)
> *** 9540,9548 ****
> 
>     containing_scope = TYPE_CONTEXT (t);
> 
> !   /* Ignore namespaces for the moment.  */
>     if (containing_scope && TREE_CODE (containing_scope) == NAMESPACE_DECL)
> !     containing_scope = NULL_TREE;
> 
>     /* Ignore function type "scopes" from the C frontend.  They mean that
>        a tagged type is local to a parmlist of a function declarator, but
> --- 9544,9563 ----
> 
>     containing_scope = TYPE_CONTEXT (t);
> 
> !   /* Handle namespaces properly */
>     if (containing_scope && TREE_CODE (containing_scope) == NAMESPACE_DECL)
> !     {
> !       dw_die_ref newcontext = lookup_decl_die (containing_scope);
> !
> !       if (!newcontext)
> !       {
> !         gen_decl_die (containing_scope, context_die);
> !         newcontext = lookup_decl_die (containing_scope);
> !         if (!newcontext)
> !           abort();
> !       }
> !       context_die = newcontext;
> !     }
> 
>     /* Ignore function type "scopes" from the C frontend.  They mean that
>        a tagged type is local to a parmlist of a function declarator, but
> *************** is_redundant_typedef (decl)
> *** 11374,11379 ****
> --- 11389,11453 ----
> 
>     return 0;
>   }
> + static dw_die_ref
> + force_out_decl (decl, context_die)
> +       tree decl;
> +       dw_die_ref context_die;
> + {
> +   /* Force out the namespace. */
> +   if (DECL_CONTEXT (decl) && TREE_CODE (DECL_CONTEXT (decl)) == NAMESPACE_DECL)
> +     {
> +       dw_die_ref newcontext;
> +       newcontext = lookup_decl_die (DECL_CONTEXT (decl));
> +       if (!newcontext)
> +       {
> +         gen_decl_die (DECL_CONTEXT (decl), context_die);
> +         newcontext = lookup_decl_die (DECL_CONTEXT (decl));
> +         if (!newcontext)
> +           abort();
> +       }
> +       context_die = newcontext;
> +     }
> +   return context_die;
> + }
> +
> + /* Generate a DIE for a namespace or namespace alias */
> + static void
> + gen_namespace_die (decl, context_die)
> +      register tree decl;
> +      register dw_die_ref context_die;
> + {
> +   /* Namespace aliases have a DECL_ABSTRACT_ORIGIN of the namespace
> +      they are an alias of.*/
> +   if (DECL_ABSTRACT_ORIGIN (decl) == NULL)
> +     {
> +       /* Output a real namespace */
> +       dw_die_ref namespace_die = new_die (DW_TAG_namespace, context_die, decl);
> +       add_name_and_src_coords_attributes (namespace_die, decl);
> +       equate_decl_number_to_die (decl, namespace_die);
> +     }
> +   else
> +     {
> +       /* Output a namespace alias */
> +       dw_die_ref namespace_die;
> +
> +       /* Force out the namespace we are an alias of, if necessary */
> +       dw_die_ref origin_die = lookup_decl_die  (DECL_ABSTRACT_ORIGIN (decl));
> +       if (!origin_die)
> +       {
> +         /* Attempt to force out origin. */
> +         dwarf2out_decl (DECL_ABSTRACT_ORIGIN (decl));
> +         origin_die = lookup_decl_die (DECL_ABSTRACT_ORIGIN (decl));
> +         if (!origin_die)
> +           abort();
> +       }
> +       /* Now create the namespace alias DIE. */
> +       namespace_die = new_die (DW_TAG_imported_declaration, context_die, decl);
> +       add_name_and_src_coords_attributes (namespace_die, decl);
> +       add_AT_die_ref (namespace_die, DW_AT_import, origin_die);
> +       equate_decl_number_to_die (decl, namespace_die);
> +     }
> + }
> 
>   /* Generate Dwarf debug information for a decl described by DECL.  */
> 
> *************** gen_decl_die (decl, context_die)
> *** 11424,11429 ****
> --- 11498,11505 ----
>         /* Otherwise we're emitting the primary DIE for this decl.  */
>         else if (debug_info_level > DINFO_LEVEL_TERSE)
>         {
> +         context_die = force_out_decl (decl, context_die);
> +
>           /* Before we describe the FUNCTION_DECL itself, make sure that we
>              have described its return type.  */
>           gen_type_die (TREE_TYPE (TREE_TYPE (decl)), context_die);
> *************** gen_decl_die (decl, context_die)
> *** 11447,11453 ****
>            actual typedefs.  */
>         if (debug_info_level <= DINFO_LEVEL_TERSE)
>         break;
> !
>         /* In the special case of a TYPE_DECL node representing the declaration
>            of some type tag, if the given TYPE_DECL is marked as having been
>            instantiated from some other (original) TYPE_DECL node (e.g. one which
> --- 11523,11529 ----
>            actual typedefs.  */
>         if (debug_info_level <= DINFO_LEVEL_TERSE)
>         break;
> !       context_die = force_out_decl (decl, context_die);
>         /* In the special case of a TYPE_DECL node representing the declaration
>            of some type tag, if the given TYPE_DECL is marked as having been
>            instantiated from some other (original) TYPE_DECL node (e.g. one which
> *************** gen_decl_die (decl, context_die)
> *** 11477,11482 ****
> --- 11553,11559 ----
>            variable declarations or definitions.  */
>         if (debug_info_level <= DINFO_LEVEL_TERSE)
>         break;
> +       context_die = force_out_decl (decl, context_die);
> 
>         /* Output any DIEs that are needed to specify the type of this data
>            object.  */
> *************** gen_decl_die (decl, context_die)
> *** 11504,11509 ****
> --- 11581,11587 ----
>         if (DECL_NAME (decl) != NULL_TREE
>           || TREE_CODE (TREE_TYPE (decl)) == UNION_TYPE)
>         {
> +         context_die = force_out_decl (decl, context_die);
>           gen_type_die (member_declared_type (decl), context_die);
>           gen_field_die (decl, context_die);
>         }
> *************** gen_decl_die (decl, context_die)
> *** 11515,11521 ****
>         break;
> 
>       case NAMESPACE_DECL:
> !       /* Ignore for now.  */
>         break;
> 
>       default:
> --- 11593,11600 ----
>         break;
> 
>       case NAMESPACE_DECL:
> !       context_die = force_out_decl (decl, context_die);
> !       gen_namespace_die (decl, context_die);
>         break;
> 
>       default:
> *************** dwarf2out_decl (decl)
> *** 11668,11673 ****
> --- 11747,11759 ----
> 
>         /* If we are in terse mode, don't generate any DIEs for types.  */
>         if (debug_info_level <= DINFO_LEVEL_TERSE)
> +     case NAMESPACE_DECL:
> +       if (debug_info_level <= DINFO_LEVEL_TERSE)
> +       return;
> +       if (lookup_decl_die (decl) != NULL)
> +         return;
> +       break;
> +
>         return;
> 
>         /* If we're a function-scope tag, initially use a parent of NULL;

Re: adding namespace support to GDB

[Daniel Berlin]

On Mon, 26 Aug 2002, Petr Sorfa wrote:

> Hi Daniel,
> 
> I'm confused. This patch is against gcc not gdb. I meant that the patch
> we will submit will be for gdb support of imported declarations.

Except the message you quoted was referring to *compiler* support for the 
debugging info.

Re: adding namespace support to GDB

[Petr Sorfa]

Hi Daniel,

Gak! My fault and apologies.

Petr
> On Mon, 26 Aug 2002, Petr Sorfa wrote:
> 
> > Hi Daniel,
> >
> > I'm confused. This patch is against gcc not gdb. I meant that the patch
> > we will submit will be for gdb support of imported declarations.
> 
> Except the message you quoted was referring to *compiler* support for the
> debugging info.

Re: adding namespace support to GDB

[Daniel Jacobowitz]

On Fri, Aug 23, 2002 at 11:41:06AM -0700, David Carlton wrote:
> In article <3D6677D3.6E84743C@caldera.com>, Petr Sorfa
> <petrs@caldera.com> writes:
> 
> > Well to help things along I will be submitting a DWARF patch that
> > will supported imported declarations which are essential for FORTRAN
> > modules and C++ namespaces.
> 
> Great, I look forward to reading it.
> 
> > This is essential for the "using" commands in either language (of
> > course the compiler needs to generate the correct DWARF
> > ;o)).
> 
> Yes, well, there is always that.  Certainly it seems like a solution
> for C++ will initially have to get recreate namespace info from
> DW_AT_MIPS_linkage_name, and there's no way that we'll be able to
> allow users to use symbol names as if all the appropriate using
> directives were in effect, since that information simply isn't in the
> debug information that GCC is currently producing.  (Though that's not
> the end of the world: we should be able to do name lookup using C++'s
> name resolution rules based on the enclosing function and its
> arguments, presumably.)

C++ certainly does _not_ need to reconstruct from
DW_AT_MIPS_linkage_name.  Everything we need should be there in
DW_TAG_namespace and DW_TAG_structure/class markers; I have patches to
use this information, with the caveats I noted in my other message.

I am gradually working on removing all uses of the physname from the
C++ debugging code.  It's a hack (and a space waste!).

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: adding namespace support to GDB

[Daniel Berlin]

On Fri, 23 Aug 2002, Daniel Jacobowitz wrote:

> On Fri, Aug 23, 2002 at 11:41:06AM -0700, David Carlton wrote:
> > In article <3D6677D3.6E84743C@caldera.com>, Petr Sorfa
> > <petrs@caldera.com> writes:
> > 
> > > Well to help things along I will be submitting a DWARF patch that
> > > will supported imported declarations which are essential for FORTRAN
> > > modules and C++ namespaces.
> > 
> > Great, I look forward to reading it.
> > 
> > > This is essential for the "using" commands in either language (of
> > > course the compiler needs to generate the correct DWARF
> > > ;o)).
> > 
> > Yes, well, there is always that.  Certainly it seems like a solution
> > for C++ will initially have to get recreate namespace info from
> > DW_AT_MIPS_linkage_name, and there's no way that we'll be able to
> > allow users to use symbol names as if all the appropriate using
> > directives were in effect, since that information simply isn't in the
> > debug information that GCC is currently producing.  (Though that's not
> > the end of the world: we should be able to do name lookup using C++'s
> > name resolution rules based on the enclosing function and its
> > arguments, presumably.)
> 
> C++ certainly does _not_ need to reconstruct from
> DW_AT_MIPS_linkage_name.  Everything we need should be there in
> DW_TAG_namespace and DW_TAG_structure/class markers; I have patches to
> use this information, with the caveats I noted in my other message.

If you hunt through the gcc patch archives, you'll find my patches to 
produce DW_AT_namespace, approved twice by Jason Merrill.

Should still apply cleanly.

> 
> I am gradually working on removing all uses of the physname from the
> C++ debugging code.  It's a hack (and a space waste!).
> 
> 

Re: adding namespace support to GDB

[Daniel Jacobowitz]

On Fri, Aug 23, 2002 at 02:48:46PM -0400, Daniel Berlin wrote:
> On Fri, 23 Aug 2002, Daniel Jacobowitz wrote:
> 
> > On Fri, Aug 23, 2002 at 11:41:06AM -0700, David Carlton wrote:
> > > In article <3D6677D3.6E84743C@caldera.com>, Petr Sorfa
> > > <petrs@caldera.com> writes:
> > > 
> > > > Well to help things along I will be submitting a DWARF patch that
> > > > will supported imported declarations which are essential for FORTRAN
> > > > modules and C++ namespaces.
> > > 
> > > Great, I look forward to reading it.
> > > 
> > > > This is essential for the "using" commands in either language (of
> > > > course the compiler needs to generate the correct DWARF
> > > > ;o)).
> > > 
> > > Yes, well, there is always that.  Certainly it seems like a solution
> > > for C++ will initially have to get recreate namespace info from
> > > DW_AT_MIPS_linkage_name, and there's no way that we'll be able to
> > > allow users to use symbol names as if all the appropriate using
> > > directives were in effect, since that information simply isn't in the
> > > debug information that GCC is currently producing.  (Though that's not
> > > the end of the world: we should be able to do name lookup using C++'s
> > > name resolution rules based on the enclosing function and its
> > > arguments, presumably.)
> > 
> > C++ certainly does _not_ need to reconstruct from
> > DW_AT_MIPS_linkage_name.  Everything we need should be there in
> > DW_TAG_namespace and DW_TAG_structure/class markers; I have patches to
> > use this information, with the caveats I noted in my other message.
> 
> If you hunt through the gcc patch archives, you'll find my patches to 
> produce DW_AT_namespace, approved twice by Jason Merrill.
> 
> Should still apply cleanly.

Huh.  I could have sworn what we need was already there; am I on crack? 
It sure looks like it from reading this debug output; I'm going to have
to find my notes... hope I still have them.

(And is DW_AT_namespace a dwarf3 thing?  I don't see it in my v2 spec.)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: adding namespace support to GDB

[David Carlton]

In article <20020823192118.GA27305@nevyn.them.org>, Daniel Jacobowitz
<drow@mvista.com> writes:

> And is DW_AT_namespace a dwarf3 thing?

Yup.

David Carlton
carlton@math.stanford.edu

Re: adding namespace support to GDB

[Daniel Berlin]

On Fri, 23 Aug 2002, Daniel Jacobowitz wrote:

> On Fri, Aug 23, 2002 at 02:48:46PM -0400, Daniel Berlin wrote:
> > On Fri, 23 Aug 2002, Daniel Jacobowitz wrote:
> > 
> > > On Fri, Aug 23, 2002 at 11:41:06AM -0700, David Carlton wrote:
> > > > In article <3D6677D3.6E84743C@caldera.com>, Petr Sorfa
> > > > <petrs@caldera.com> writes:
> > > > 
> > > > > Well to help things along I will be submitting a DWARF patch that
> > > > > will supported imported declarations which are essential for FORTRAN
> > > > > modules and C++ namespaces.
> > > > 
> > > > Great, I look forward to reading it.
> > > > 
> > > > > This is essential for the "using" commands in either language (of
> > > > > course the compiler needs to generate the correct DWARF
> > > > > ;o)).
> > > > 
> > > > Yes, well, there is always that.  Certainly it seems like a solution
> > > > for C++ will initially have to get recreate namespace info from
> > > > DW_AT_MIPS_linkage_name, and there's no way that we'll be able to
> > > > allow users to use symbol names as if all the appropriate using
> > > > directives were in effect, since that information simply isn't in the
> > > > debug information that GCC is currently producing.  (Though that's not
> > > > the end of the world: we should be able to do name lookup using C++'s
> > > > name resolution rules based on the enclosing function and its
> > > > arguments, presumably.)
> > > 
> > > C++ certainly does _not_ need to reconstruct from
> > > DW_AT_MIPS_linkage_name.  Everything we need should be there in
> > > DW_TAG_namespace and DW_TAG_structure/class markers; I have patches to
> > > use this information, with the caveats I noted in my other message.
> > 
> > If you hunt through the gcc patch archives, you'll find my patches to 
> > produce DW_AT_namespace, approved twice by Jason Merrill.
> > 
> > Should still apply cleanly.
> 
> Huh.  I could have sworn what we need was already there; am I on crack?

Must be, i never committed it.
Because GDB's wouldn't just ignore it, it would ignore all the children, 
so without a GDB that supports it, it severely affects the debuggability.
 
> It sure looks like it from reading this debug output; I'm going to have
> to find my notes... hope I still have them.
I guarantee you it doesn't produce DW_AT_namespace right now.
I'll resubmit the patch again today if you like.

> 
> (And is DW_AT_namespace a dwarf3 thing?  I don't see it in my v2 spec.)

Yup.

> 
> 

Re: adding namespace support to GDB

[Jason Molenda]

On Fri, Aug 23, 2002 at 03:21:18PM -0400, Daniel Jacobowitz wrote:

> 
> (And is DW_AT_namespace a dwarf3 thing?  I don't see it in my v2 spec.)
> 

The Dwarf3 standard is at its 8th draft, open for public review for about
ten months now.  The web page coordinating the committee's work is here -

	http://www.eagercon.com/dwarf/dwarf3std.htm

There's only a link to draft7 on that page for reasons I don't understand; 
draft8 is available here -
	http://reality.sgiweb.org/davea/dwarf3-draft8-011125.pdf

It may be that draft 8 is draft 7 rebranded as the Public Review
draft, but I don't really know.

Dave Anderson has written a helpful comparison of DWARF2 and DWARF3 on
his web site -
	http://reality.sgiweb.org/davea

Jason

Re: adding namespace support to GDB

[David Carlton]

In article <20020823184746.GA25528@nevyn.them.org>, Daniel Jacobowitz
<drow@mvista.com> writes:
> On Fri, Aug 23, 2002 at 11:41:06AM -0700, David Carlton wrote:

>> Certainly it seems like a solution for C++ will initially have to
>> get recreate namespace info from DW_AT_MIPS_linkage_name, and
>> there's no way that we'll be able to allow users to use symbol
>> names as if all the appropriate using directives were in effect,
>> since that information simply isn't in the debug information that
>> GCC is currently producing.

> C++ certainly does _not_ need to reconstruct from
> DW_AT_MIPS_linkage_name.  Everything we need should be there in
> DW_TAG_namespace and DW_TAG_structure/class markers; I have patches
> to use this information, with the caveats I noted in my other
> message.

Sure, if the file being debugged is appropriately tagged with
DW_TAG_namespace.  (And, of course, with DW_TAG_structure/class_type,
and other compound data structures; currently, GCC generates
DW_TAG_structure_type instead of DW_TAG_class_type, but I don't think
that should have much of a practical effect on GDB.)

But we can't refuse to debug C++ code that was produced by a version
of GCC that doesn't generate those tags.  And, right now, the only way
we can get an approximation to namespace information is by looking at
the contents of DW_AT_MIPS_linkage_name.  There are still flaws with
that other than not seeing using directives - e.g. I don't think
there's any way to tell what namespace an enum lives in from the
information that GCC currently produces - but it's a start.

> I am gradually working on removing all uses of the physname from the
> C++ debugging code.  It's a hack (and a space waste!).

Right.  I'm not suggesting that we keep the physnames around
indefinitely.  There's information in DW_AT_MIPS_linkage_name that I
think we need currently, but that doesn't mean that we can't discard
it after using it.  E.g. it makes sense to me that, if GDB runs into a
class declaration, it would grab the DW_AT_MIPS_linkage_name of its
first member, demangle it and figure out where in the namespace
hierarchy the class under investigation lives, and then keep that
information around; once it's done that, it doesn't need to use the
DW_AT_MIPS_linkage_name of any of the other members, let alone keep
them around indefinitely.

David Carlton
carlton@math.stanford.edu

Re: adding namespace support to GDB

[Daniel Jacobowitz]

On Fri, Aug 23, 2002 at 08:42:40AM -0700, David Carlton wrote:
> I recently asked Daniel Jacobwitz for suggestions as to what I could
> do to help GDB, and he suggested that I might try adding proper
> namespace support.  I've skimmed a thread on the issue from early
> April with lots of interesting ideas; at some point, it sounded like
> Jim Blandy was about to start writing up some concrete possible
> interfaces, and I was wondering if anything more came of that.
> 
> For the time being, I'm going to reread that thread more closely, look
> at Petr Sorfa's module patch, look at the DWARF-3 standard, look at
> existing GDB code, and think about this for a while.  (Or at least I
> hope that's what I'm going to do: maybe I'll instead spend all of my
> time arguing with Stanford's benefits office.  Anybody know of any
> interesting free software jobs in countries with nationalized health
> insurance?)  But I don't want to duplicate effort if somebody else has
> already started working on this.

Meanwhile, I'm working on ugly namespace support - without all the
symbol table and scoping work that we'll need to make things quite
"correct", I'm trying to make the debug readers provide scope
information (mostly done) and the rest of GDB cope with it
(investigating).  I have patches for both stabs and DWARF-2 to generate
class and types names properly qualified, but because the rest of GDB
doesn't expect this they never get unqualified; we get things like

  std::bar std::bar::function(std::bar&)

because it doesn't know that the std:: can be elided.  Etc.

Hope to have more time to work on this next week.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: adding namespace support to GDB

[Daniel Jacobowitz]

On Fri, Aug 23, 2002 at 02:06:35PM -0400, Daniel Jacobowitz wrote:
> On Fri, Aug 23, 2002 at 08:42:40AM -0700, David Carlton wrote:
> > I recently asked Daniel Jacobwitz for suggestions as to what I could
> > do to help GDB, and he suggested that I might try adding proper
> > namespace support.  I've skimmed a thread on the issue from early
> > April with lots of interesting ideas; at some point, it sounded like
> > Jim Blandy was about to start writing up some concrete possible
> > interfaces, and I was wondering if anything more came of that.
> > 
> > For the time being, I'm going to reread that thread more closely, look
> > at Petr Sorfa's module patch, look at the DWARF-3 standard, look at
> > existing GDB code, and think about this for a while.  (Or at least I
> > hope that's what I'm going to do: maybe I'll instead spend all of my
> > time arguing with Stanford's benefits office.  Anybody know of any
> > interesting free software jobs in countries with nationalized health
> > insurance?)  But I don't want to duplicate effort if somebody else has
> > already started working on this.
> 
> Meanwhile, I'm working on ugly namespace support - without all the
> symbol table and scoping work that we'll need to make things quite
> "correct", I'm trying to make the debug readers provide scope
> information (mostly done) and the rest of GDB cope with it
> (investigating).  I have patches for both stabs and DWARF-2 to generate
> class and types names properly qualified, but because the rest of GDB
> doesn't expect this they never get unqualified; we get things like
> 
>   std::bar std::bar::function(std::bar&)
> 
> because it doesn't know that the std:: can be elided.  Etc.
> 
> Hope to have more time to work on this next week.

Well, for the amusement of our audience, here's code to do this for
stabs.  This isn't an RFA, since GDB isn't ready for this data.  It's
also not quite right; it handles TYPE_NAME but not TYPE_TAG_NAME, since
I'm still not 100% sure what TYPE_TAG_NAME ought to be.  I suspect I
should just set it at the same time as setting TYPE_NAME in
read_member_functions.

With this, the return type from methods in
class C {
  class D {
  };
};

is written as C::D instead of D.  The symbol's name is still wrong, so
GDB thinks the type is D instead of C::D, still.  And there's a missing
optimization (only call class_name_from_physname once per class).  But
you get the picture...

With this technique to get the information, the next step will be to
remove it in the appropriate places, like in printing; that requires
passing around the current name prefix all the time.  When we know what
it is.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Index: gdbtypes.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtypes.c,v
retrieving revision 1.55
diff -u -p -r1.55 gdbtypes.c
--- gdbtypes.c	10 Aug 2002 05:12:40 -0000	1.55
+++ gdbtypes.c	23 Aug 2002 21:16:23 -0000
@@ -3431,6 +3431,41 @@ build_gdbtypes (void)
 	       "__bfd_vma", (struct objfile *) NULL);
 }
 
+char *
+class_name_from_physname (const char *physname)
+{
+  char *p, *end;
+  int depth = 0;
+  char *demangled_name = cplus_demangle (physname, DMGL_ANSI);
+
+  if (demangled_name == NULL)
+    return;
+
+  p = end = demangled_name;
+  while (*p && *p != ' ' && *p != '(')
+    {
+      if (depth == 0 && *p == ':' && *(p+1) == ':')
+	end = p;
+      else if (depth == '<' || depth == '(')
+	depth++;
+      else if (depth == '>' || depth == ')')
+	depth--;
+      p++;
+    }
+
+  if (end != demangled_name)
+    {
+      char *ret;
+      ret = xmalloc (end - demangled_name + 1);
+      memcpy (ret, demangled_name, end - demangled_name);
+      ret[end - demangled_name] = '\0';
+      xfree (demangled_name);
+      return ret;
+    }
+
+  xfree (demangled_name);
+  return NULL;
+}
 
 extern void _initialize_gdbtypes (void);
 void
Index: gdbtypes.h
===================================================================
RCS file: /cvs/src/src/gdb/gdbtypes.h,v
retrieving revision 1.35
diff -u -p -r1.35 gdbtypes.h
--- gdbtypes.h	10 Aug 2002 05:12:40 -0000	1.35
+++ gdbtypes.h	23 Aug 2002 21:16:24 -0000
@@ -1130,6 +1130,8 @@ extern struct type *lookup_primitive_typ
 
 extern char *gdb_mangle_name (struct type *, int, int);
 
+extern char *class_name_from_physname (const char *physname);
+
 extern struct type *builtin_type (char **);
 
 extern struct type *lookup_typename (char *, struct block *, int);
Index: stabsread.c
===================================================================
RCS file: /cvs/src/src/gdb/stabsread.c,v
retrieving revision 1.38
diff -u -p -r1.38 stabsread.c
--- stabsread.c	1 Aug 2002 17:18:32 -0000	1.38
+++ stabsread.c	23 Aug 2002 21:16:28 -0000
@@ -44,6 +44,7 @@
 #include "demangle.h"
 #include "language.h"
 #include "doublest.h"
+#include "cp-abi.h"
 
 #include <ctype.h>
 
@@ -136,8 +137,7 @@ static int
 attach_fields_to_type (struct field_info *, struct type *, struct objfile *);
 
 static struct type *read_struct_type (char **, struct type *,
-                                      enum type_code,
-				      struct objfile *);
+                                      enum type_code, struct objfile *);
 
 static struct type *read_array_type (char **, struct type *,
 				     struct objfile *);
@@ -3093,6 +3093,9 @@ rs6000_builtin_type (int typenum)
    $ is the CPLUS_MARKER (usually '$'), `*' holds the place for an operator
    name (such as `+=') and `.' marks the end of the operator name.
 
+   If we read at least one method with a complete physname, set
+   TYPE_NAME (TYPE) appropriately.
+
    Returns 1 for success, 0 for failure.  */
 
 static int
@@ -3225,6 +3228,25 @@ read_member_functions (struct field_info
 	    }
 	  new_sublist->fn_field.physname = savestring (*pp, p - *pp);
 	  *pp = p + 1;
+
+	  /* This is needed because GCC doesn't output the complete name of
+	     the class, for e.g. nested classes.  For v3 there are no
+	     abbreviated physnames, so we can find the real class name
+	     from a synthetic or real constructor;  for v2 in nested classes
+	     the synthetic constructor [or a real one] is generally (always?)
+	     present, and because its physname is mangled starting with two
+	     underscores instead of starting with the method name, the
+	     physname is included unabbreviated.  */
+	  if (is_constructor_name (new_sublist->fn_field.physname))
+	    {
+	      char *class_name
+		= class_name_from_physname (new_sublist->fn_field.physname);
+
+	      /* G++ anonymous structures have names starting with '.'.  */
+	      if (class_name[0] != '.')
+		TYPE_NAME (type) = obconcat (&objfile->type_obstack, "",
+					     "", class_name);
+	    }	  
 
 	  /* Set this member function's visibility fields.  */
 	  switch (*(*pp)++)

Re: adding namespace support to GDB

[David Carlton]

In article <ro1hehloa33.fsf@jackfruit.Stanford.EDU>, David Carlton
<carlton@math.Stanford.EDU> writes:

> For the time being, I'm going to reread that thread more closely,
> look at Petr Sorfa's module patch, look at the DWARF-3 standard,
> look at existing GDB code, and think about this for a while.

I haven't really done much of that yet, but I did look over some of
the messages in that thread and take some notes based on that combined
with some thought that I have on the issue.  The notes don't contain
much (any?) information along the lines of "exactly what in GDB do we
have to change to make this work", since I'm still new enough to GDB's
internals not to have a global feel for them to be confident about
this and and I didn't have time today to poke into GDB's code all that
much.  But at least it's a concrete list of issues to keep in mind.

So here the notes are; any comments would be gratefully appreciated.
This is, of course, a rough draft: I'm sending it off now more because
it's 5:00 and I want to head home for the weekend than because I think
it's particularly complete or anything.


Some notes on namespace-related issues:

* The goal is to provide a general framework for associating data
  (types, locations, etc.) to names (variable names, type names, etc.)
  Let's tentatively call this an 'environment'.

* For some discussion of this, see the thread starting from
  <http://sources.redhat.com/ml/gdb/2002-04/msg00072.html>.

* Language contexts where this happens:

  * Compound statements.  In C, function bodies, bodies of loops, etc.

  * Compound data structures.  E.g. classes in C++ or Java.  (Warning:
    I'm learning C++ reasonably quickly, I hope, but there's a lot to
    learn.  And I read a book about Java once...)  Not to mention
    simpler examples: C structures, unions.

  * Compound name structures.  C++ namespaces, Fortran modules
    (warning: I know zero about Fortran), Java packages.  Are there
    any other such structures in languages that GDB supports?
    Probably files combined with static global variables in C go in
    here.  (For that matter, extern global variables also go in here.)

  This trichotomy is not a hard-and-fast distinction, needless to say.
  For example, in C++, you often have the choice about whether to use
  a namespace or a class with static members in a given situation, and
  similarly a Java programmer would use a class with static members in
  many situations where a C++ programmer would use a namespace.

  I'll typically stick to C++ examples.

* According to Jim Blandy (in the message referenced above), existing
  GDB constructs that these environments could replace are:

  * In 'struct block', to represent local variables, replacing 'nsym'
    and 'sym'.

  * In 'struct type', to represent fields, replacing 'struct fields'.

  But here I think he's only referring to local environments: there's
  also the global environment.

* Here are some issues surrounding environments:

  * How does GDB initialize the environment structures?

  * How does GDB figure out in what environments to search for a name
    that a user types in?

  * How should we implement environments internally?

* Right now, I'm not worried about the first problem so much.  Having
  said that, here are some issues that are relevant to it:

  * If the compiler generates rich enough debugging information, then
    we don't have to worry too much about how to initialize the
    environment structures: we have everything we need given to us.

  * If the compiler doesn't generate rich enough debugging
    information, then we can still do a decent approximation to the
    correct information by, say, looking at mangled linkage names for
    symbols.  It's not perfect, but it'll do fine.

  * I'm not sure _exactly_ how we'll detect whether or not we've got
    enough debugging information when reading the info for a given
    file, but we can figure out something.  (E.g. for C++, use mangled
    linkage names until we first see a DW_TAG_namespace.)

  * For some environments, we can count on being able to easily figure
    out a complete picture of what it looks like: this should be true
    for compound data structures and compound statements.  But it's
    not true for many sorts of compound name structures: stuff can get
    added to the global environment or to namespaces in somewhat
    unpredictable ways.  Still, I don't think this is _too_ serious:
    having an analogue to the partial symbol table around plus reading
    in detailed debugging information for an entire file at a time
    should mean that we never miss information that we need.  (How
    does the minimal symbol table come in to play?)

* The second problem seems to me to be considerably more subtle; even
  with perfect debugging information, it's not clear to me that, at
  least initially, we'd implement C++'s name lookup rules completely.

  * Different languages vary considerably in exactly what information
    is accessible at any given point.

  * Environments usually form a "tree" in some vague sense, but
    exactly what that tree means (and its implications in terms of
    environment search rules) varies considerably based on the type of
    environment.  For example, if you don't find a symbol in the
    current compound statement, you can always go up to the enclosing
    compound statement.  Whereas, if you have a C++ namespace B nested
    inside a C++ namespace A, then even if you make symbols inside
    A::B accessible via a 'using' declaration, symbols inside A aren't
    necessarily accessible.

  * Often, language constructs for making compound name structures
    accessible (C++ 'using' declarations, etc.) permit some amount of
    renaming.

  * Some compound name structures don't have names.  One example is
    files + static global variables in C; another example is anonymous
    namespaces in C++.  (Note that the second example is a superset of
    the first example: the first example is basically like the special
    case of the second example in which the parent of the anonymous
    namespace is the global namespace.)

  * If the compiler doesn't generate rich enough debugging
    information, we simply won't be able to do a perfect job here.
    (Though I think we'll be able to do a good enough job that users
    will forgive us.)

  * When doing a lookup, the user may provide part of the name prefix
    in addition to the variable name.

  * Functions can be overloaded, so sometimes you need types as well
    as the name.

  * Do virtual member functions and/or virtual base classes pose
    problems?  I don't think they do, but I'll list them just in case.

  * Anything else?  I think I'm probably leaving out stuff here.  I'm
    not too familiar with what GDB's current data structures are for
    representing what names are accessible at a given point.

* Then there's the issue of implementing environments internally.

  * One issue to keep in mind is that different environments can have
    dramatically different numbers of names.  E.g. the global
    environment is potentially extremely large, as is C++'s 'std'
    namespace; but a struct is typically quite small, as the
    namespaces in code that I write myself.

    So we need a data structure that can deal with these extremes.  In
    particular, linear lists of names and fixed-size hash tables both
    sound like bad ideas to me.  Does GDB or libiberty or whatever
    have tools for dealing with heaps or hash tables that grow as
    necessary?  (Is it even a good idea to grow your hash tables as
    you add entries to them?  My theoretical background in algorithms
    and data structures is weak.)

  * If we look up a name in an environment, what data do we want that
    name lookup to return to us?  If what we're looking up is a
    variable, then candidates are type information and location
    information.  But of course we might want to look up other things
    (structures/classes/unions, typedefs, enums, namespaces, etc.)
    Should we only search based on names, or search based on names +
    what kind of object we want to associate to that name?  (Probably
    the latter.)

* Are we going to try to implement this incrementally or not?  On a
  separate branch or on the mainline branch?  What recent patches to
  GDB (whether proposed or approved) help with this effort?


David Carlton
carlton@math.stanford.edu

Re: adding namespace support to GDB

[David Anderson]

Jason Molenda writes:
>        http://www.eagercon.com/dwarf/dwarf3std.htm
>
>There's only a link to draft7 on that page for reasons I don't understand; 
>draft8 is available here -
>        http://reality.sgiweb.org/davea/dwarf3-draft8-011125.pdf
>
>It may be that draft 8 is draft 7 rebranded as the Public Review
>draft, but I don't really know.

No, draft 7 is obsolete now. Use draft 8.  I don't recall the
changes as being significant, but it is  probably not a good
idea to reference draft 7.  The dwarf committee had been
planning one method of publishing dwarf3 and we were waiting
for certain things to happen. For various reasons the intended
approach no longer seems viable for us.  (leaving this all
vague intentionally :-)

So we will be  (hopefully soon, but no promises) creating a new
web site for dwarf.  However, I cannot promise when that would
happen.  Because of the hiatus, the public comment period is
not considered to have really started yet (though comments on
'draft 8' on the dwarf2 email list (dwarf2@els.sgi.com) would
be welcome at any time).  I am the owner/maintainer of
the list, so list issues should be sent to me.

>Dave Anderson has written a helpful comparison of DWARF2 and DWARF3 on
>his web site -
>        http://reality.sgiweb.org/davea

Thanks.  Corrections and suggestions on the comparison
document are welcome: send such to me or the dwarf2 list (your
choice).

Regards,
David B. Anderson davea@sgi.com http://reality.sgiweb.org/davea