]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit
Pass dwarf2_cu objects to dwo-related functions, instead of dwarf2_per_cu_data
authorSimon Marchi <simon.marchi@efficios.com>
Wed, 26 Feb 2020 03:47:57 +0000 (22:47 -0500)
committerSimon Marchi <simon.marchi@efficios.com>
Tue, 12 May 2020 19:24:50 +0000 (15:24 -0400)
commit9e575d411d7a7ddfb72786a011788ae22fa5bd01
tree137a3650cb6e737304761b0875f57ab63dac1e12
parente734976f6c9614291d80502ca5a59acba6b0f12b
Pass dwarf2_cu objects to dwo-related functions, instead of dwarf2_per_cu_data

This allows removing references to the
dwarf2_per_cu_data::dwarf2_per_objfile field.

I am not too sure of the code flow here, but ultimately
open_and_init_dwo_file calls create_cus_hash_table, and passes it
per_cu->cu.  create_cus_hash_table requires a dwarf2_cu to pass to
cutu_reader, as the "parent_cu".

The dwarf2_per_cu_data::cu link is only set when in a certain context.
It's not easy to convince myself in which situations it's safe to use
it.  Instead, if a function is going to use a dwarf2_cu, I think it's
simpler if it takes that object directly.  If it needs access to the
corresponding dwarf2_per_cu_data object, then it can used the
dwarf2_cu::per_cu field, which we know is always set.

This patch adds some references to dwarf2_per_cu_data::cu in the
cutu_reader context.  In this context, we know this field will be set,
as it's cutu_reader that is responsible for instantiating the dwarf2_cu
and assigning the field.

gdb/ChangeLog:

* dwarf2/read.c (lookup_dwo_comp_unit): Change
dwarf2_per_cu_data parameter fo dwarf2_cu.
(lookup_dwo_type_unit): Likewise.
(read_cutu_die_from_dwo): Likewise.
(lookup_dwo_unit): Likewise.
(open_and_init_dwo_file): Likewise.
(lookup_dwo_cutu): Likewise.
(lookup_dwo_comp_unit): Likewise.
(lookup_dwo_type_unit): Likewise.
(cutu_reader::init_tu_and_read_dwo_dies): Update.
(cutu_reader::cutu_reader): Update.
gdb/dwarf2/read.c