Rename new_symfile_objfile to finish_new_objfile.
Commit Message
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
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.
@@ -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);
@@ -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);