aboutsummaryrefslogtreecommitdiff
path: root/sim/rx
diff options
context:
space:
mode:
authorSimon Marchi <simon.marchi@polymtl.ca>2021-04-02 11:50:45 -0400
committerSimon Marchi <simon.marchi@polymtl.ca>2021-04-02 11:51:45 -0400
commit9161c89ad8a1a1bf079a5538ce19b467a9457b84 (patch)
treeca4962bdf18c61d540e6cf56c4bcdafdbd8684ab /sim/rx
parent0072c873792829e2be43acf8bbf1c352c266e4c7 (diff)
downloadgdb-9161c89ad8a1a1bf079a5538ce19b467a9457b84.zip
gdb-9161c89ad8a1a1bf079a5538ce19b467a9457b84.tar.gz
gdb-9161c89ad8a1a1bf079a5538ce19b467a9457b84.tar.bz2
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
Diffstat (limited to 'sim/rx')
0 files changed, 0 insertions, 0 deletions