* objfiles.h (struct objfile): Remove obsolete comment.

* objfiles.c (build_objfile_section_table): Remove obsolete
	comment.

gdb/ChangeLog

@@ -1,3 +1,9 @@
+2011-12-08  Tom Tromey  <tromey@redhat.com>
+
+	* objfiles.h (struct objfile): Remove obsolete comment.
+	* objfiles.c (build_objfile_section_table): Remove obsolete
+	comment.
+
 2011-12-07  Stan Shebs  <stan@codesourcery.com>
 
 	* MAINTAINERS (Responsible Maintainers): Add Yao Qi as

gdb/objfiles.c

@@ -162,12 +162,6 @@ add_to_objfile_sections (struct bfd *abfd, struct bfd_section *asect,
 int
 build_objfile_section_table (struct objfile *objfile)
 {
-  /* objfile->sections can be already set when reading a mapped symbol
-     file.  I believe that we do need to rebuild the section table in
-     this case (we rebuild other things derived from the bfd), but we
-     can't free the old one (it's in the objfile_obstack).  So we just
-     waste some memory.  */
-
   objfile->sections_end = 0;
   bfd_map_over_sections (objfile->obfd,
 			 add_to_objfile_sections, (void *) objfile);

gdb/objfiles.h

@@ -173,19 +173,9 @@ struct objfile
   {
 
     /* All struct objfile's are chained together by their next pointers.
-       The global variable "object_files" points to the first link in this
-       chain.
-
-       FIXME:  There is a problem here if the objfile is reusable, and if
-       multiple users are to be supported.  The problem is that the objfile
-       list is linked through a member of the objfile struct itself, which
-       is only valid for one gdb process.  The list implementation needs to
-       be changed to something like:
-
-       struct list {struct list *next; struct objfile *objfile};
-
-       where the list structure is completely maintained separately within
-       each gdb process.  */
+       The program space field "objfiles"  (frequently referenced via
+       the macro "object_files") points to the first link in this
+       chain.  */
 
     struct objfile *next;