gdb/dwarf: create and destroy dwarf2_per_bfd's CUs-to-expand queue

As described in the log of patch "gdb/dwarf: add assertion in
maybe_queue_comp_unit", it would happen that a call to
maybe_queue_comp_unit would enqueue a CU in the to-expand queue while
nothing up the stack was processing the queue.  This is not desirable,
as items are then left lingering in the queue when we exit the
dwarf2/read code.  This is an inconsistent state.

The normal case of using the queue is when we go through
dw2_do_instantiate_symtab and process_queue.  As depended-on CUs are
found, they get added to the queue.  process_queue expands CUs until the
queue is empty.

To catch these cases where things are enqueued while nothing up the
stack is processing the queue, change dwarf2_per_bfd::queue to be an
optional.  The optional is instantiated in dwarf2_queue_guard, just
before where we call process_queue.  In the dwarf2_queue_guard
destructor, the optional gets reset.  Therefore, the queue object is
instantiated only when something up the stack is handling it.  If
another entry point tries to enqueue a CU for expansion, an assertion
will fail and we know we have something to fix.

dwarf2_queue_guard sounds like the good place for this, as it's
currently responsible for making sure the queue gets cleared if we exit
due to an error.

This also allows asserting that when age_comp_units or remove_all_cus
run, the queue is not instantiated, and gives us one more level of
assurance that we won't free the DIEs of a CU that is in the
CUs-to-expand queue.

gdb/ChangeLog:

	PR gdb/26828
	* dwarf2/read.c (dwarf2_queue_guard) <dwarf2_queue_guard>:
	Instantiate queue.
	(~dwarf2_queue_guard): Clear queue.
	(queue_comp_unit): Assert that queue is
	instantiated.
	(process_queue): Adjust.
	* dwarf2/read.h (struct dwarf2_per_bfd) <queue>: Make optional.

Change-Id: I8fe3d77845bb4ad3d309eac906acebe79d9f0a9d

0 files changed, 0 insertions, 0 deletions