Introduce dwarf2_cu::get_builder

This patch is an attempt to deal with a variety of bugs reported where
GDB segfaults attempting to access a dwarf2_cu's builder.  In certain
circumstances, this builder can be NULL.  This is especially common
when inheriting DIEs via inlined subroutines in other CUs.  The test
case demonstrates one such situation reported by users.  See gdb/23773,
rhbz1638798, and dups for other concrete examples.

The approach taken here is to save the ancestor CU into the dwarf2_cu of
all CUs with DIEs that are "imported."  This can happen whenever
follow_die_offset and friends are called.  This essentially introduces a
chain of CUs that caused the importation of a DIE from a CU.  Whenever
a builder is requested of a CU that has none, the ancestors are searched
for the first one with a builder.

A design side effect of this is that the builder can now only be
accessed by getter and setter methods because the builder itself
is private.

The bulk of the patch is relatively mindless text conversion from
"cu->builder" to "cu->get_builder ()".  I've included one test which
was derived from one (of the many) bugs reported on the issue in both
sourceware and Fedora bugzillas.

gdb/ChangeLog:

	PR gdb/23773
	* dwarf2read.c (dwarf2_cu) <ancestor>: New field.
	<builder>: Rename to ..
	<m_builder>: ... this and make private.
	(dwarf2_cu::get_builder): New method.  Change all users of
	`builder' to use this method.
	(dwarf2_start_symtab): Move to ...
	(dwarf2_cu::start_symtab): ... here.  Update all callers
	(setup_type_unit_groups): Move to ...
	(dwarf2_cu::setup_type_unit_groups): ... here.  Update all
	callers.
	(dwarf2_cu::reset_builder): New method.
	(process_full_compunit, process_full_type_unit): Use
	dwarf2_cu::reset_builder.
	(follow_die_offset): Record the ancestor CU if it is different
	from the followed DIE's CU.
	(follow_die_sig_1): Likewise.

gdb/testsuite/ChangeLog:

	PR gdb/23773
	* gdb.dwarf2/inlined_subroutine-inheritance.exp: New file.

0 files changed, 0 insertions, 0 deletions