tree 76c64dbd0b960afdd49b239ffc7ef68ab179952c
parent b1b6ea0cb0296a3cb29d98671bc15371e5ab467c
author Simon Marchi <simon.marchi@efficios.com> 1741926773 -0400
committer Simon Marchi <simon.marchi@efficios.com> 1741969421 -0400

gdb/dwarf: assume that source_cu->dies is always set in follow_die_offset

After staring at the code for a while, I got convinced that it's not
possible for cu->dies to be nullptr in follow_die_offset.  It might be a
leftover from the psymtab days.

In most cases, we see that the dwarf2_cu passedas `*ref_cu` has been
obtained by doing:

    per_objfile->get_cu (per_cu);

The only way for a dwarf2_cu to end up in the per_objfile like this is
through load_full_comp_unit or read_signatured_type.  Both of these
functions call `reader.read_all_dies ()` (which loads the DIEs in memory
and assigns dwarf2_cu::dies) before transferring the newly created
dwarf2_cu to the per_objfile.  So any dwarf2_cu obtained through

   per_objfile->get_cu (per_cu)

... will have its DIEs set.

The only case today I'm aware of of a dwarf2_cu without DIEs is in the
cooked indexer.  It creates a cutu_reader, but does not call
read_all_dies.  Instead, it gets the info_ptr from the cutu_reader and
reads the DIEs from the section buffer directly, on its own.  But this
is an entirely different code path that doesn't assign dwarf2_cu
objects to per_objfile.

So, remove the code path in follow_die_offset that tests for
`source_cu->dies == NULL`.  I added an assert at the top of the function
to verify that `source_cu->dies` is always non-nullptr, as a way to
test my hypothesis.  We could probably get rid of it, but I left it
there because it doesn't cost much to have it.

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