gdb/dwarf: assume that no dwarf2_cu exist when calling load_full_comp_unit

After staring at the code, I got convinced that it was not possible for
load_full_comp_unit to be called while a dwarf2_cu object exists in
per_objfile for this_cu.  If you follow all callers of
load_full_comp_unit, you can see that all calls to load_full_comp_unit
(except one, see below) are gated one way or another by the fact that:

  per_objfile->get_cu (per_cu) == nullptr

Some calls are gated by maybe_queue_comp_unit returning true.  If it
returns true, then necessarily the dwarf2_cu is unset for that per_cu.

The spot that didn't seem to check for whether the dwarf2_cu is already
set before calling load_full_comp_unit is dw2_do_instantiate_symtab.  It
didn't trigger when running the testsuite, but I could imagine a made up
case where the dwarf2_cu would already be set because we looked up a DIE
reference to it (follow_die_ref) for whatever reason.  Then, something
would cause the symtab for that CU to be expanded and
dw2_do_instantiate_symtab to be called.

I added a check in that function, because it seemed prudent to do so.
All other load_cu calls are gated by this check, so it makes this call
look just like the others.

Finally, because all call sites that use cutu_reader::release_cu pass
nullptr for `existing_cu` (and therefore cutu_reader creates a new
dwarf2_cu), we know that cutu_reader::release_cu will always return a
non-nullptr value.  Add an assert in it and remove checks in
load_full_comp_unit and read_signatured_type.

Change-Id: I496be34bd4bf7edfa38d5135cf4bc4ccd960abe2
Approved-By: Tom Tromey <tom@tromey.com>

0 files changed, 0 insertions, 0 deletions