diff mbox

D: support reading modules from DWARF

Message ID CABOHX+cT+Zucmxn7jfuRF-hH-5scjiWGSf3wzDCZXXRfnN8-Tg@mail.gmail.com
State New, archived
Headers

Commit Message

Iain Buclaw July 13, 2015, 5:47 p.m. UTC 
  Hi,

D uses modules (DW_TAG_module), but to separate the namespace of every
source file.  Modules can be imported into each other, either publicly
or privately (DW_TAG_imported_module).  Or declarations can be
selectively imported or renamed (DW_TAG_imported_decl).

This patch pretty much just extends the existing support for
namespaces/modules in C++/Fortran/Java to include language_d too.
However unlike Fortran/C++, the separator for qualified names is a
single dot.

This will need to be followed up with a patch to support looking up
symbols in D module 'namespaces'.  However I'm currently unsure
whether to either extend cp-namespace.c, or to go ahead with my
current fork (d-namespace.c), which copies only what's needed,
adjusting for D-specific symbol import logic.

Iain.

Comments

Pedro Alves July 14, 2015, 9:12 a.m. UTC | #1 
On 07/13/2015 06:47 PM, Iain Buclaw wrote:
> Hi,
> 
> D uses modules (DW_TAG_module), but to separate the namespace of every
> source file.  Modules can be imported into each other, either publicly
> or privately (DW_TAG_imported_module).  Or declarations can be
> selectively imported or renamed (DW_TAG_imported_decl).
> 
> This patch pretty much just extends the existing support for
> namespaces/modules in C++/Fortran/Java to include language_d too.
> However unlike Fortran/C++, the separator for qualified names is a
> single dot.

OK.

Thanks,
Pedro Alves
Doug Evans July 18, 2015, 6:01 p.m. UTC | #2 
Iain Buclaw <ibuclaw@gdcproject.org> writes:
> Hi,
>
> D uses modules (DW_TAG_module), but to separate the namespace of every
> source file.  Modules can be imported into each other, either publicly
> or privately (DW_TAG_imported_module).  Or declarations can be
> selectively imported or renamed (DW_TAG_imported_decl).
>
> This patch pretty much just extends the existing support for
> namespaces/modules in C++/Fortran/Java to include language_d too.
> However unlike Fortran/C++, the separator for qualified names is a
> single dot.
>
> This will need to be followed up with a patch to support looking up
> symbols in D module 'namespaces'.  However I'm currently unsure
> whether to either extend cp-namespace.c, or to go ahead with my
> current fork (d-namespace.c), which copies only what's needed,
> adjusting for D-specific symbol import logic.

Hi.

Re: cp-namespace.c:
Hard to say without seeing the patch,
but having spent a lot of time cleaning up cp-namespace.c
I'm not fond of complicating it again to handle more languages.

So, and again I'd have to see the patch to be sure,
I'd say plan on going with d-namespace.c.
Iain Buclaw July 20, 2015, 7:11 a.m. UTC | #3 
On 18 July 2015 at 20:01, Doug Evans <xdje42@gmail.com> wrote:
> Iain Buclaw <ibuclaw@gdcproject.org> writes:
>> Hi,
>>
>> D uses modules (DW_TAG_module), but to separate the namespace of every
>> source file.  Modules can be imported into each other, either publicly
>> or privately (DW_TAG_imported_module).  Or declarations can be
>> selectively imported or renamed (DW_TAG_imported_decl).
>>
>> This patch pretty much just extends the existing support for
>> namespaces/modules in C++/Fortran/Java to include language_d too.
>> However unlike Fortran/C++, the separator for qualified names is a
>> single dot.
>>
>> This will need to be followed up with a patch to support looking up
>> symbols in D module 'namespaces'.  However I'm currently unsure
>> whether to either extend cp-namespace.c, or to go ahead with my
>> current fork (d-namespace.c), which copies only what's needed,
>> adjusting for D-specific symbol import logic.
>
> Hi.
>
> Re: cp-namespace.c:
> Hard to say without seeing the patch,
> but having spent a lot of time cleaning up cp-namespace.c
> I'm not fond of complicating it again to handle more languages.
>
> So, and again I'd have to see the patch to be sure,
> I'd say plan on going with d-namespace.c.

Thanks, I see you have found the other patch I was referring to.

Assuming that you are intimate with cp-namespace.c, I might have to
pick your brains for a couple of things that should be possible, but
are currently not.  However with the current homework I've done so
far, I suspect that I'll have to request an amendment for inclusion in
the next DWARFv5 specification first before anything else.

Regards
Iain.
diff mbox

Patch

2015-07-13  Iain Buclaw  <ibuclaw@gdcproject.org>

	* dwarf2read.c (find_slot_in_mapped_hash): Extend language support to
	also test for language_d.
	(dwarf2_compute_name): Likewise.
	(read_func_scope): Likewise.
	(read_structure_type): Likewise.
	(determine_prefix): Likewise.
	(read_import_statement): Use dot as the separator for language_d.
	(typename_concat): Likewise, but don't prefix the D main function.

--- a/gdb/dwarf2read.c
+++ b/gdb/dwarf2read.c
@@ -2974,7 +2974,8 @@  find_slot_in_mapped_hash (struct mapped_index *index, const char *name,
 
   if (current_language->la_language == language_cplus
       || current_language->la_language == language_java
-      || current_language->la_language == language_fortran)
+      || current_language->la_language == language_fortran
+      || current_language->la_language == language_d)
     {
       /* NAME is already canonical.  Drop any qualifiers as .gdb_index does
 	 not contain any.  */
@@ -8463,7 +8464,7 @@  dwarf2_compute_name (const char *name,
   /* These are the only languages we know how to qualify names in.  */
   if (name != NULL
       && (cu->language == language_cplus || cu->language == language_java
-	  || cu->language == language_fortran))
+	  || cu->language == language_fortran || cu->language == language_d))
     {
       if (die_needs_namespace (die, cu))
 	{
@@ -8941,8 +8942,9 @@  read_import_statement (struct die_info *die, struct dwarf2_cu *cu)
     }
   else if (strlen (imported_name_prefix) > 0)
     canonical_name = obconcat (&objfile->objfile_obstack,
-			       imported_name_prefix, "::", imported_name,
-			       (char *) NULL);
+			       imported_name_prefix,
+			       (cu->language == language_d ? "." : "::"),
+			       imported_name, (char *) NULL);
   else
     canonical_name = imported_name;
 
@@ -11445,7 +11447,9 @@  read_func_scope (struct die_info *die, struct dwarf2_cu *cu)
                         lowpc, highpc);
 
   /* For C++, set the block's scope.  */
-  if ((cu->language == language_cplus || cu->language == language_fortran)
+  if ((cu->language == language_cplus
+       || cu->language == language_fortran
+       || cu->language == language_d)
       && cu->processing_has_namespace_info)
     block_set_scope (block, determine_prefix (die, cu),
 		     &objfile->objfile_obstack);
@@ -13140,7 +13144,8 @@  read_structure_type (struct die_info *die, struct dwarf2_cu *cu)
   if (name != NULL)
     {
       if (cu->language == language_cplus
-	  || cu->language == language_java)
+	  || cu->language == language_java
+	  || cu->language == language_d)
 	{
 	  const char *full_name = dwarf2_full_name (name, die, cu);
 
@@ -19228,7 +19233,7 @@  determine_prefix (struct die_info *die, struct dwarf2_cu *cu)
   char *retval;
 
   if (cu->language != language_cplus && cu->language != language_java
-      && cu->language != language_fortran)
+      && cu->language != language_fortran && cu->language != language_d)
	return "";
 
   retval = anonymous_struct_prefix (die, cu);
@@ -19384,6 +19389,18 @@  typename_concat (struct obstack *obs, const char *prefix, const char *suffix,
     sep = "";
   else if (cu->language == language_java)
     sep = ".";
+  else if (cu->language == language_d)
+    {
+      /* For D, the 'main' function could be defined in any module, but it
+	 should never be prefixed.  */
+      if (strcmp (suffix, "D main") == 0)
+	{
+	  prefix = "";
+	  sep = "";
+	}
+      else
+	sep = ".";
+    }
   else if (cu->language == language_fortran && physname)
     {
       /* This is gfortran specific mangling.  Normally DW_AT_linkage_name or