Always use dwarf2_initialize_objfile
authorTom Tromey <tromey@adacore.com>
Tue, 19 Apr 2022 17:32:04 +0000 (11:32 -0600)
committerTom Tromey <tromey@adacore.com>
Thu, 21 Apr 2022 18:18:25 +0000 (12:18 -0600)
commit31de881f8f9a03499002d28ff42286b79c24a97d
tree5b53fb49b9872daf60c36d0fe78f6c9ad0553fe5
parent5f21c7aae2040f3463d1ff56a4b0bcdbba34832d
Always use dwarf2_initialize_objfile

Internally we noticed that some tests would fail like so on Windows:

warning: Section .debug_aranges in [...] has duplicate debug_info_offset 0x0, ignoring .debug_aranges.

Debugging showed that, in fact, a second CU was being created at this
offset.  We tracked this down to the fact that, while the ELF reader
is careful to re-use the per-BFD data, other readers are not, and
could re-read the DWARF data multiple times.

However, since the change to allow an objfile to have multiple "quick
symbol" implementations, there's no reason for this approach -- it's
safe and easy for all symbol readers to reuse the per-BFD data when
reading DWARF.

This patch implements this idea, simplifying dwarf2_build_psymtabs and
making it private, and then switching to dwarf2_initialize_objfile as
the sole way to start the DWARF reader.

Note that, while I think the call to dwarf2_build_frame_info in
machoread.c is also obsolete, I haven't attempted to remove it here.
gdb/coffread.c
gdb/dwarf2/public.h
gdb/dwarf2/read.c
gdb/machoread.c
gdb/xcoffread.c