search for: debugfissiondwp

Much like the recent efforts to provide a port of dsymutil in the LLVM project, I'm looking at providing an implementation of the Fission/Split DWARF DWP tool ( https://gcc.gnu.org/wiki/DebugFissionDWP ) in LLVM. While there's potentially some overlap between the two tools, I'm thinking of keeping them separate at least initially since much of the debug info doesn't need to be touched by a DWP tool, unlike dsymutil. Basically all the tool needs to do is concatenate (or deduplicate,...

...GDB does good things with this, except with Fission. > > Can you lay out the terminology you are using here? Is Fission as used > here different/more than creating .dwo files? > Fission as used in that sentence means .dwo files and anything beyond (.dwp files - https://gcc.gnu.org/wiki/DebugFissionDWP ). GDB warns/errors/complains if two CUs are in a single .dwo, and ignores all but the first. > > > Binutils DWP produces usable DWPs from DWO files with multiple CUs > > > > 2) Cross-CU references > > This is where it gets trickier. > > LLVM produces cross-CU ref...

...ngs with this, except with Fission. >> >> Can you lay out the terminology you are using here? Is Fission as used here different/more than creating .dwo files? >> >> Fission as used in that sentence means .dwo files and anything beyond (.dwp files - https://gcc.gnu.org/wiki/DebugFissionDWP <https://gcc.gnu.org/wiki/DebugFissionDWP> ). GDB warns/errors/complains if two CUs are in a single .dwo, and ignores all but the first. > > It sounds like having more than one CU per .dwo is outside of the intention of the DWARF specification (though not explicitly forbidden), since t...

...M, David Blaikie via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Much like the recent efforts to provide a port of dsymutil in the LLVM >> project, I'm looking at providing an implementation of the Fission/Split >> DWARF DWP tool ( https://gcc.gnu.org/wiki/DebugFissionDWP ) in LLVM. >> >> While there's potentially some overlap between the two tools, I'm >> thinking of keeping them separate at least initially since much of the >> debug info doesn't need to be touched by a DWP tool, unlike dsymutil. >> >> Basically all t...

...ames collide. > GDB does good things with this, except with Fission. Can you lay out the terminology you are using here? Is Fission as used here different/more than creating .dwo files? Fission as used in that sentence means .dwo files and anything beyond (.dwp files - https://gcc.gnu.org/wiki/DebugFissionDWP ). GDB warns/errors/complains if two CUs are in a single .dwo, and ignores all but the first. It sounds like having more than one CU per .dwo is outside of the intention of the DWARF specification (though not explicitly forbidden), since there is an implied 1-1 relationship between skeleton CU and...

...s-section are harmfull together. Probably it worth to restrict using of them together or >>emit a warning (both clang and gcc silently allows the combination and output has size penalty you describing). > >Nah, only if you're not producing a DWP at the end ( https://gcc.gnu.org/wiki/DebugFissionDWP ). Sure DWP do great job here it seems, but even for DWP use case flow it does not look make sence to force compiler to do excessive job to produce types sections, ​because DWP producing tools probably should have no benefit from larger .dwo files with .debug_types at all I think. I can only imag...

>If you're interested in things you can do in the linker for this - you might consider something more aggressive: Fully DWARF aware deduplication. > >This could be done hopefully by reusing some of the code in the dsymutil implementation in LLVM. > >This would be much more effective (and without the possible context-sensitive tradeoffs) than using type units. >Though

So Dehao and I have been dealing with some of the nitty gritty details of debug info with ThinLTO, specifically with Fission(Split DWARF). This applies to LTO as well, so I won't single out ThinLTO here. 1) Multiple CUs in a .dwo file Clang/LLVM produces a CU for each original source file - these CUs are kept through IR linking (thin or full) and produced as distinct CUs in the resulting