search for: dwp

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 t...

On Tue, Nov 3, 2015 at 5:06 PM, Alexey Samsonov <vonosmas at gmail.com> wrote: > SGTM. This will bring us closer to the point when we can write tests, > where we strip out the .dwo files from executables, package them together > with llvm-dwp, and then verify that we still get all we need from > llvm-symbolizer. > Not quite following here - dwo sections are already stripped from .o files and should never appear in executables. llvm-symbolizer is tested against .o files that contain no dwo contents, right? Or is the dwo/dwp infor...

...en if their names 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. > > > Binutils DWP produces usable DWPs from DWO files with multiple CUs > > > > 2) Cross-CU references > > This is where it ge...

...e bytes are already present in another file, etc) in > http://reviews.llvm.org/D17694 . In theory there's some overlap with lld > here (no doubt it already does this sort of thing, but not in a way, I > assume, we could reuse from other tools at the moment) and my motivation, > llvm-dwp, looks very much like "linking with a few extra steps". > > But to check that these changes might be more generally applicable, I > thought I'd solicit data from anyone building tools that might be memory > constrained as well. > > First that comes to mind (Eric sugg...

...lide. >> > 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 <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 specifi...

...es/Makefile2:21803: recipe for target 'tools/dsymutil/CMakeFiles/dsymutil.dir/all' failed make[1]: *** [tools/dsymutil/CMakeFiles/dsymutil.dir/all] Error 2 clang: error: unable to execute command: Killed clang: error: linker command failed due to signal (use -v to see invocation) tools/llvm-dwp/CMakeFiles/llvm-dwp.dir/build.make:230: recipe for target 'bin/llvm-dwp' failed make[2]: *** [bin/llvm-dwp] Error 254 CMakeFiles/Makefile2:24606: recipe for target 'tools/llvm-dwp/CMakeFiles/llvm-dwp.dir/all' failed make[1]: *** [tools/llvm-dwp/CMakeFiles/llvm-dwp.dir/all] Error 2 c...

...ull) and produced as distinct CUs in the resulting DWARF. This preserves semantics as much as possible - eg: file-local functions and types (those in anonymous namespaces or declared file-static) con co-exist even if their names collide. GDB does good things with this, except with Fission. 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 references (DW_FORM_ref_addr) to refer to types or functions defined in one CU used from another. This only happens with (thin or plain) LTO. LLVM's had this for...

...-static) con co-exist even if their names 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...

...ols/dsymutil/CMakeFiles/dsymutil.dir/all' failed > > make[1]: *** [tools/dsymutil/CMakeFiles/dsymutil.dir/all] Error 2 > > clang: error: unable to execute command: Killed > > clang: error: linker command failed due to signal (use -v to see > invocation) > > tools/llvm-dwp/CMakeFiles/llvm-dwp.dir/build.make:230: recipe for target > 'bin/llvm-dwp' failed > > make[2]: *** [bin/llvm-dwp] Error 254 > > CMakeFiles/Makefile2:24606: recipe for target > 'tools/llvm-dwp/CMakeFiles/llvm-dwp.dir/all' failed > > make[1]: *** [tools/llvm-dw...

...ady present in another file, etc) in >> http://reviews.llvm.org/D17694 . In theory there's some overlap with lld >> here (no doubt it already does this sort of thing, but not in a way, I >> assume, we could reuse from other tools at the moment) and my motivation, >> llvm-dwp, looks very much like "linking with a few extra steps". >> >> But to check that these changes might be more generally applicable, I >> thought I'd solicit data from anyone building tools that might be memory >> constrained as well. >> >> First that...

...sonable to (and if anyone would be interested in doing it) do >something more like the PDB support - fully debug-aware linking. Honestly saying I only know how ELF linker works and may be my thoughts below are silly for some reason or duplicating some already existent approach. Looking at what .dwp do, looks there are two main things reducing size debug data: 1) "It must allow for the removal of duplicate type units". 2) "It must allow for the removal of duplicate strings". Linker already deduplicates strings by itself, though it can delegate it to some API for debug sect...

.../all' failed > >> > make[1]: *** [tools/dsymutil/CMakeFiles/dsymutil.dir/all] Error 2 > >> > clang: error: unable to execute command: Killed > >> > clang: error: linker command failed due to signal (use -v to see > invocation) > >> > tools/llvm-dwp/CMakeFiles/llvm-dwp.dir/build.make:230: recipe for > target 'bin/llvm-dwp' failed > >> > make[2]: *** [bin/llvm-dwp] Error 254 > >> > CMakeFiles/Makefile2:24606: recipe for target > 'tools/llvm-dwp/CMakeFiles/llvm-dwp.dir/all' failed > >> >...

...present in another file, etc) in http://reviews.llvm.org/D17694 <http://reviews.llvm.org/D17694> . In theory there's some overlap with lld here (no doubt it already does this sort of thing, but not in a way, I assume, we could reuse from other tools at the moment) and my motivation, llvm-dwp, looks very much like "linking with a few extra steps". >> >> But to check that these changes might be more generally applicable, I thought I'd solicit data from anyone building tools that might be memory constrained as well. >> >> First that comes to mind (E...

...present in another file, etc) in http://reviews.llvm.org/D17694 <http://reviews.llvm.org/D17694> . In theory there's some overlap with lld here (no doubt it already does this sort of thing, but not in a way, I assume, we could reuse from other tools at the moment) and my motivation, llvm-dwp, looks very much like "linking with a few extra steps". >> >> But to check that these changes might be more generally applicable, I thought I'd solicit data from anyone building tools that might be memory constrained as well. >> >> First that comes to mind (E...

...>> what, 6 or 7x slower than linking without the feature?) for most users >>>>>>> to consider it a good trade-off. >>>>>> It seems to me that even the current 6x-7x slowdown could be useful. >>>>>> Users who already use dsymutil or llvm-dwp(assuming DWARFLinker >>>>>> would be taught to work with a split dwarf) tools spend this time and, >>>>>> in some scenarios, waste disk space by inter-mediate files. >>>>> FWIW, dwp (llvm-dwp hasn't really been optimized compared to binutils &g...

...lower than linking without the feature?) for most users >>>>>>>>> to consider it a good trade-off. >>>>>>>> It seems to me that even the current 6x-7x slowdown could be useful. >>>>>>>> Users who already use dsymutil or llvm-dwp(assuming DWARFLinker >>>>>>>> would be taught to work with a split dwarf) tools spend this time and, >>>>>>>> in some scenarios, waste disk space by inter-mediate files. >>>>>>> FWIW, dwp (llvm-dwp hasn't really been optimized...

...present in another file, etc) in http://reviews.llvm.org/D17694 <http://reviews.llvm.org/D17694> . In theory there's some overlap with lld here (no doubt it already does this sort of thing, but not in a way, I assume, we could reuse from other tools at the moment) and my motivation, llvm-dwp, looks very much like "linking with a few extra steps". >>> >>> But to check that these changes might be more generally applicable, I thought I'd solicit data from anyone building tools that might be memory constrained as well. >>> >>> First that...

...have a buffer, or the bytes are already present in another file, etc) in http://reviews.llvm.org/D17694 . In theory there's some overlap with lld here (no doubt it already does this sort of thing, but not in a way, I assume, we could reuse from other tools at the moment) and my motivation, llvm-dwp, looks very much like "linking with a few extra steps". But to check that these changes might be more generally applicable, I thought I'd solicit data from anyone building tools that might be memory constrained as well. First that comes to mind (Eric suggested/mentioned) is llvm-dsy...

...gt;> >what, 6 or 7x slower than linking without the feature?) for most users >> >> >to consider it a good trade-off. >> >> >> >> It seems to me that even the current 6x-7x slowdown could be useful. >> >> Users who already use dsymutil or llvm-dwp(assuming DWARFLinker >> >> would be taught to work with a split dwarf) tools spend this time and, >> >> in some scenarios, waste disk space by inter-mediate files. >> > >> >FWIW, dwp (llvm-dwp hasn't really been optimized compared to binutils >> &...

...for most users > >>>>>>>>> to consider it a good trade-off. > >>>>>>>> It seems to me that even the current 6x-7x slowdown could > be useful. > >>>>>>>> Users who already use dsymutil or llvm-dwp(assuming > DWARFLinker > >>>>>>>> would be taught to work with a split dwarf) tools spend > this time and, > >>>>>>>> in some scenarios, waste disk space by inter-mediate files. > >>>>>>> FWIW, d...