diff mbox

Rename new_symfile_objfile to finish_new_objfile.

Message ID yjt2wq3uioic.fsf@ruffy.mtv.corp.google.com
State New, archived
Headers

Commit Message

Doug Evans Feb. 6, 2015, 11:55 p.m. UTC 
  Hi.

I'm tempted to just commit this patch, but in case anyone wants to
comment ...

clear_symtab_users is in need of a bit of cleanup.
I can see how doing things a little differently would make this part of gdb
that much more obvious and clean. I started to go down this road
but ran out of time (for the moment at least).

I still want to get this part in.
The name "new_symfile_objfile" is confusing.
"symfile_objfile" has a very specific meaning: it is the piece of global
state that records the "main" objfile. Thus one would naturally expect
that new_symfile_objfile would only be called when there's a new main objfile.
However, this is not the case. :-(

To remove this bit of confusion this patch renames the function.

And since it has only one caller in the same file I made it static.
That helps limit the scope of things one needs to think about when
cleaning up clear_symtab_users.

2015-02-06  Doug Evans  <dje@google.com>

	* symfile.h (new_symfile_objfile): Delete.
	* symfile.c (finish_new_objfile): Renamed from new_symfile_objfile.
	All callers updated.

Comments

Doug Evans Feb. 11, 2015, 1:04 a.m. UTC | #1 
On Fri, Feb 6, 2015 at 3:55 PM, Doug Evans <dje@google.com> wrote:
> Hi.
>
> I'm tempted to just commit this patch, but in case anyone wants to
> comment ...
>
> clear_symtab_users is in need of a bit of cleanup.
> I can see how doing things a little differently would make this part of gdb
> that much more obvious and clean. I started to go down this road
> but ran out of time (for the moment at least).
>
> I still want to get this part in.
> The name "new_symfile_objfile" is confusing.
> "symfile_objfile" has a very specific meaning: it is the piece of global
> state that records the "main" objfile. Thus one would naturally expect
> that new_symfile_objfile would only be called when there's a new main objfile.
> However, this is not the case. :-(
>
> To remove this bit of confusion this patch renames the function.
>
> And since it has only one caller in the same file I made it static.
> That helps limit the scope of things one needs to think about when
> cleaning up clear_symtab_users.
>
> 2015-02-06  Doug Evans  <dje@google.com>
>
>         * symfile.h (new_symfile_objfile): Delete.
>         * symfile.c (finish_new_objfile): Renamed from new_symfile_objfile.
>         All callers updated.

Committed.
diff mbox

Patch

diff --git a/gdb/symfile.c b/gdb/symfile.c
index 5ae5000..c2a71ec 100644
--- a/gdb/symfile.c
+++ b/gdb/symfile.c
@@ -1099,8 +1099,8 @@  syms_from_objfile (struct objfile *objfile,
    symbols for a new objfile, or mapping in the symbols from a reusable
    objfile.  ADD_FLAGS is a bitmask of enum symfile_add_flags.  */
 
-void
-new_symfile_objfile (struct objfile *objfile, int add_flags)
+static void
+finish_new_objfile (struct objfile *objfile, int add_flags)
 {
   /* If this is the main symbol file we have to clean up all users of the
      old main symbol file.  Otherwise it is sufficient to fixup all the
@@ -1234,7 +1234,7 @@  symbol_file_add_with_addrs (bfd *abfd, const char *name, int add_flags,
       return objfile;	/* No symbols.  */
     }
 
-  new_symfile_objfile (objfile, add_flags);
+  finish_new_objfile (objfile, add_flags);
 
   observer_notify_new_objfile (objfile);
 
diff --git a/gdb/symfile.h b/gdb/symfile.h
index a22ee04..0bf40c1 100644
--- a/gdb/symfile.h
+++ b/gdb/symfile.h
@@ -458,8 +458,6 @@  enum symfile_add_flags
     SYMFILE_NO_READ = 1 << 4
   };
 
-extern void new_symfile_objfile (struct objfile *, int);
-
 extern struct objfile *symbol_file_add (const char *, int,
 					struct section_addr_info *, int);