aboutsummaryrefslogtreecommitdiff
path: root/gdb/solib-svr4.c
diff options
context:
space:
mode:
authorSimon Marchi <simon.marchi@efficios.com>2023-10-10 16:28:03 +0000
committerSimon Marchi <simon.marchi@efficios.com>2023-10-19 10:57:51 -0400
commit38dc8f35f92f9b0f7306eaa8ee26097b1e8f4d3f (patch)
tree8cad8d972539a82a0f5193464d764c25b2a09777 /gdb/solib-svr4.c
parent8971d2788e79db2ffc1205ed36935483eedf2fab (diff)
downloadgdb-38dc8f35f92f9b0f7306eaa8ee26097b1e8f4d3f.zip
gdb-38dc8f35f92f9b0f7306eaa8ee26097b1e8f4d3f.tar.gz
gdb-38dc8f35f92f9b0f7306eaa8ee26097b1e8f4d3f.tar.bz2
gdb: don't call so_list::clear in free_so
I think this `so.clear ()` call is not useful. - so_list::clear deletes some things that now get automatically deleted when the so_list gets deleted right after in free_so. - so_list::clear resets some scalar fields of so_list, which we don't really care about since the so_list gets deleted right after. - so_list::clear calls target_so_ops::clear_so, of which there is a single implementation, svr4_clear_so. That implementation just resets a field in lm_info_svr4, which we don't care about, as it will get deleted when the so_list gets deleted right after. Change-Id: Ie4d72f2a04a4129e55c460bb5c69bc0af0d12b32 Approved-By: Pedro Alves <pedro@palves.net> Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
Diffstat (limited to 'gdb/solib-svr4.c')
0 files changed, 0 insertions, 0 deletions