This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
(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.
Attachment:
multiple_cus_per_dwo.diff
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |