Preliminary cleanup for splitting host/native/target.

[deliverable/binutils-gdb.git] / gdb / buildsym.c

diff --git a/gdb/buildsym.c b/gdb/buildsym.c
index e0f69cddc61e539ba415e415e656942a67413ec4..a25190a6168054fd9b1e698bb85e84cf23984ce5 100644 (file)
--- a/gdb/buildsym.c
+++ b/gdb/buildsym.c
@@ -549,7 +549,14 @@ start_symtab (name, dirname, start_addr)
    (creating struct block's for them), then make the struct symtab
    for that file and put it in the list of all such.
 
-   END_ADDR is the address of the end of the file's text.  */
+   END_ADDR is the address of the end of the file's text.
+
+   Note that it is possible for end_symtab() to return NULL.  In particular,
+   for the DWARF case at least, it will return NULL when it finds a
+   compilation unit that has exactly one DIE, a TAG_compile_unit DIE.  This
+   can happen when we link in an object file that was compiled from an empty
+   source file.  Returning NULL is probably not the correct thing to do,
+   because then gdb will never know about this empty file (FIXME). */
 
 struct symtab *
 end_symtab (end_addr, sort_pending, sort_linevec, objfile)
@@ -583,7 +590,7 @@ end_symtab (end_addr, sort_pending, sort_linevec, objfile)
        }
     }
 
-  /* It is unfortunate that in aixcoff, pending blocks might not be ordered
+  /* It is unfortunate that in xcoff, pending blocks might not be ordered
      in this stage. Especially, blocks for static functions will show up at
      the end.  We need to sort them, so tools like `find_pc_function' and
      `find_pc_block' can work reliably. */
@@ -642,7 +649,7 @@ end_symtab (end_addr, sort_pending, sort_linevec, objfile)
     }
 
 #ifdef PROCESS_LINENUMBER_HOOK
-  PROCESS_LINENUMBER_HOOK ();                  /* Needed for aixcoff. */
+  PROCESS_LINENUMBER_HOOK ();                  /* Needed for xcoff. */
 #endif
 
   /* Now create the symtab objects proper, one for each subfile.  */