Fission support for multiple CUs per DWO file

  (previous thread: https://sourceware.org/ml/gdb-patches/2017-04/msg00749.html )

LLVM LTO (ThinLTO, full LTO, any other situation where two LLVM
modules with debug info are merged into one/cross imported, etc)
produces multiple CUs in a single object file.

The best guess at how this should be combined with Fission (though it
seem there's any particular plan/spec for this, so it's a bit
off-label, for sure), is that multiple skeletons and dwo CUs should be
produced - but all dwo CUs in one .dwo file (matching (actually
objcopy'd out of) the .o file produced) and all the skeleton CUs
providing that one/same file name as the dwo_name.

Here's a patch to support that and seems to work well with LLVM's output here.

[An extra wrinkle is that LLVM would normally try to use
DW_FORM_ref_addr to refer to entities across the CU boundary (types,
to avoid duplicating type information in each CU, abstract
subprograms/variables to avoid duplication and accurately reflect
cross-CU inlining (eg: a file-local function (namespace static, or
anonymous namespace) in one CU might end inlined into a function in
another CU)). The problem with this is that the DWP format doesn't
carry enough information currently to make this possible (the INFO
column contains only the contribution of a single CU, even if it came
from a multi-CU DWO file - so there's no way to know where to resolve
the ref_addr relative to). So for now I've added a workaround to LLVM
to duplicate rather than using ref_addr in this case. But I hope/plan
to fix this as soon as possible once a reasonable format can be
decided on (see dwarf-discuss mailing list thread) and DWP tool and
GDB are fixed to address that. But for now, multiple CUs in a DWO
without cross-CU references is still valuable]

gdb/ChangeLog:

2017-05-12  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.
        (static void 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.

gdb/testsuite/ChangeLog:

2017-05-12  David Blaikie  <dblaikie@gmail.com>

        * gdb.dwarf2/fission-multi-cu.S: Test containing multiple CUs
in a DWO, built from fission-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
while 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 for the
multi-CU-single-DWO test.

Fission support for multiple CUs per DWO file

Commit Message

Patch