Fission support for multiple CUs per DWO file

In some cases a compiler may produce a single object file (& thus single
DWO file) representing multiple source files. The most common example of
this is in whole program optimization (such as LLVM's LTO). Fission may
still be a beneficial feature to use here - to avoid the need to
read/link the debug info with system libraries and the like.

This change adds basic support for multiple CUs in a single DWO file to
support LLVM's output in this situation.

There is still outstanding work to design and implement a solution for
cross-CU references (usually using DW_FORM_ref_addr) in this scenario.
For now LLVM works around this by duplicating DIEs rather than making
cross-CU references in DWO files. This degrades debugger
behavior/quality especially for file-local entities.

2017-07-06  David Blaikie  <dblaikie@gmail.com>

	* dwarf2read.c (struct dwo_file): Use a htab of dwo_unit* (rather than
	a singular dwo_unit*) to support multiple CUs in the same way that
	multiple TUs are supported.
	(create_cus_hash_table): Replace create_dwo_cu with a function for
	parsing multiple CUs from a DWO file.
	(open_and_init_dwo_file): Use create_cus_hash_table rather than
	create_dwo_cu.
	(lookup_dwo_cutu): Lookup CU in the hash table in the dwo_file with
	htab_find, rather than comparing the signature to a singleton CU in
	the dwo_file.

2017-07-06  David Blaikie  <dblaikie@gmail.com>

	* gdb.dwarf2/fission-multi-cu.S: Test containing multiple CUs in a DWO,
	built from fissiont-multi-cu{1,2}.c.
	* gdb.dwarf2/fission-multi-cu.exp: Test similar to fission-base.exp,
	except putting 'main' and 'func' in separate CUs in the same DWO file.
	* gdb.dwarf2/fission-multi-cu1.c: First CU for the multi-CU-single-DWO
	test.
	* gdb.dwarf2/fission-multi-cu2.c: Second CU in the multi-CU-single-DWO
	test.

0 files changed, 0 insertions, 0 deletions