gdb: remove objfile parameter from get_objfile_bfd_data
authorSimon Marchi <simon.marchi@polymtl.ca>
Fri, 2 Apr 2021 15:50:45 +0000 (11:50 -0400)
committerSimon Marchi <simon.marchi@polymtl.ca>
Fri, 2 Apr 2021 15:51:45 +0000 (11:51 -0400)
commit9161c89ad8a1a1bf079a5538ce19b467a9457b84
treeca4962bdf18c61d540e6cf56c4bcdafdbd8684ab
parent0072c873792829e2be43acf8bbf1c352c266e4c7
gdb: remove objfile parameter from get_objfile_bfd_data

I noticed it was unused.  I think that makes sense, as it shows that
objfile_per_bfd_storage is not specific to one objfile (it can be shared
by multiple objfiles that have the same bfd).

There is one thing I wonder though, maybe I'm missing something.  If
the BFD doesn't require relocation, get_objfile_bfd_data stores the
newly allocated object in objfiles_bfd_data, so we can assume that
objfiles_bfd_data is the owner of the object.  When the bfd's refcount
drops to 0, the corresponding objfile_per_bfd_storage object in
objfiles_bfd_data is deleted.

But if the BFD requires relocation, get_objfile_bfd_data returns a newly
allocated object that isn't kept anywhere else (and isn't shared).  So
the objfile becomes the owner of the objfile_per_bfd_storage object.  In
objfile::~objfile, we have this:

    if (obfd)
      gdb_bfd_unref (obfd);
    else
      delete per_bfd;

I'm thinking that obfd could be non-nullptr, and it could require
relocation.  In that case, it would never be freed.  Anyway, that's not
really connected to this patch.

gdb/ChangeLog:

* objfiles.c (get_objfile_bfd_data): Remove objfile parameter,
adjust callers.

Change-Id: Ifa3158074ea6b42686780ba09d0c964b0cf14cf1
gdb/ChangeLog
gdb/objfiles.c