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

* objfiles.c (build_objfile_section_table): Remove obsolete
	comment.
This commit is contained in:
Tom Tromey 2011-12-08 18:08:12 +00:00
parent d8ea793193
commit ff011ed785
3 changed files with 9 additions and 19 deletions

View file

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

View file

@ -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);

View file

@ -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;