search for: dwo

Hi, I am still struggling with my optimized/speedup build of llvm-toolchain v3.8.1. Here: Enable LTO, PGO, optimized-TableGen, split-DWARF and build with GNU/gold and LLVMgold-plugin. The objcopy (binutils v2.22) here on Ubuntu/precise AMD64 does not support '--extract-dwo'. My build fails with... /usr/bin/objcopy: unrecognized option '--extract-dwo'. Now, I did a full build of binutils v2.26.1 and using its binaries. Is it possible to embed a test if objcopy is able to perform '--extract-dwo'? ( I cannot say which of the speedup options requir...

There's no requirement that DW_AT_ranges (or high/low_pc) appear on the skeleton CU rather than the DWO CU. So it's quite possible that to get the address ranges covered by the CU one would need to look in the DWO, I think? Is that not correct/have I misunderstood something there? The DWO isn't supposed to contain addresses (because it isn't supposed to contain relocations). In DWARF 5...

Sorry, trying to catch up a bit late… 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 .dwo. There is an explicit 1-1 relationship between skeleton CU and split-full CU (not .dwo). This suggests to me that if you want a .dwo to...

...>> > 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 DWARF. >> > This preserves semantics as much as possible - eg: file-local functions and types (those in anonymous n...

...ote: > > > > 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 DWARF. > > This preserves semantics as much as possible - eg: file-local functions > and types (those in anon...

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

...ing code (lines 335-339): https://github.com/llvm-mirror/llvm/blob/master/lib/DebugInfo/DWARF/DWARFUnit.cpp#L335 Object I used for debugging parser is following: t.ii: int a; clang++ -gsplit-dwarf -c t.ii -o t.o When parser tries to read this object it attemps to extract address ranges from dwo. When we don't give it .debug_str it fails to extract dwo name, exits early and "works" fine, but with .debug_str provided it tries to take ranges from there, tries to get DWO name to open it and fails. Though I did not find why it tries to scan .dwo. I tried to comment these line...

David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> writes: > On Thu, Nov 16, 2017 at 11:44 AM Robinson, Paul <paul.robinson at sony.com> > wrote: > >> There's no requirement that DW_AT_ranges (or high/low_pc) appear on the >> skeleton CU rather than the DWO CU. So it's quite possible that to get the >> address ranges covered by the CU one would need to look in the DWO, I think? >> >> Is that not correct/have I misunderstood something there? >> >> The DWO isn't supposed to contain addresses (because it isn't su...

...utable (or linker "-r" output) where all input files use the standard DWARF style can be handled exactly the same way. The linker will append all the .debug_str_offsets contributions together, do all the relocations, and the net result is a new sequence of headers and arrays. (b) For a .dwo file, the compiler produces a .debug_str_offsets.dwo section, which is laid out like a single "contribution" in the .o file (that is, there is one header describing the entire section, and only one array of offsets). Unlike the .o file, the DWARF spec says units in the .dwo file do *not*...

...e 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, in the case of type units) the sections and apply a few domain-specific relocations, but that doesn't include having to read the DIE tree in debug_info.dwo (only the headers). The other thing is to build a couple of indexing data structures to allow fast lookup of CUs and TUs. Likely I'll start with: * adding llvm-dwarfdump support for the DWP indexes * basic prototype of llvm-dwp just concatenating sections * handle each of the domain specific...

...lining failure: $ cat asan.cpp __attribute__((always_inline)) inline void func(int* i) { *i = 3; } int main() { func(nullptr); } The failures before this change: #0 0x4a320e in func(int*) /tmp/dbginfo/asan.cpp:1:59 #1 0x4a320e in main /tmp/dbginfo/asan.cpp:4 And then if we delete the .dwo (to simulate running on another machine, etc, etc): #0 0x4a320e in main /tmp/dbginfo/asan.cpp:1:59 So we get the expected weird mixed stack frame. Then, with the improvements, we see: #0 0x4a320e in func /tmp/dbginfo/asan.cpp:1:59 #1 0x4a320e in main /tmp/dbginfo/asan.cpp:4 One min...

...eup I concluded that it cannot do that. str_offsets_base points to the element immediately after the header. You can have multiple units sharing the (entire) same contribution, but there's no slicing. I think there'd be some point/benefit to being able to have multiple contributions in a DWO file, but I don't think it's /buggy/ that it's not allowed - just a possible future enhancement. The trick with having multiple contributions in a DWO is that the .debug_line.dwo section has no way to specify which contribution to use. I mean, you could identify which CU points to tha...

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 DWARF. This preserves semantics as much as possible - eg: file-local functions and types (those in anonymous namespaces or declared file-s...

...; in a split-DWARF (fission) scenario, as there is no .debug_str_offsets > section in a non-split pre-V5 compilation AFAIK. Oh, of course! So a normal object file is always standard. Excellent! > > And given that we don't have a DW_AT_str_offsets_base attribute in > .debug_info.dwo sections by standard decree, all units (whether standard > V5 or GCC-style) would have to share the single contribution in the > .debug_str_offsets.dwo section (or the single contribution in a slice of > the section via dwp index table). > > So the only tricky part for the reader wo...

...<llvm-dev at lists.llvm.org> writes: > > > On Thu, Nov 16, 2017 at 11:44 AM Robinson, Paul <paul.robinson at sony.com> > > wrote: > > > >> There's no requirement that DW_AT_ranges (or high/low_pc) appear on the > >> skeleton CU rather than the DWO CU. So it's quite possible that to get > the > >> address ranges covered by the CU one would need to look in the DWO, I > think? > >> > >> Is that not correct/have I misunderstood something there? > >> > >> The DWO isn't supposed to contain...

...s.llvm.org> writes: > > > 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. > > When are the .dwo files produced? If at link time, what is the advantage > of using fission? Normally the advantage is the faster link, but if it > is the linker producing them, what is left? > For ThinLTO they are produced by the backends, and only the split .o part needs to be linked. I think that benefi...

...ze-properties" "-fcxx-exceptions" "-fexceptions" "-fdiagnostics-show-option" "-fcolor-diagnostics" "-vectorize-slp" "-o" "/tmp/a-b567ef.o" "-x" "c++" "a.cc" "-split-dwarf-file" "a.dwo" "/usr/bin/objcopy" "--extract-dwo" "/tmp/a-b567ef.o" "a.dwo" "/usr/bin/objcopy" "--strip-dwo" "/tmp/a-b567ef.o" "/usr/bin/ld" "-z" "relro" "--hash-style=gnu" "--build-id"...

....org>> writes: > > > 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. > > When are the .dwo files produced? If at link time, what is the advantage > of using fission? Normally the advantage is the faster link, but if it > is the linker producing them, what is left? > > For ThinLTO they are produced by the backends, and only the split .o part needs to be linked. I think that b...

...that ideal, now, for ELF. Maybe only these three things need to be done? -- >  1. Teach lld how to emit a separated debuginfo output file directly, without requiring an objcopy step. >  2. Integrate DWARFLinker into lld. >  3. Create a new tool which takes the separated debuginfo and DWO/DWP files and uses DWARFLinker library > to create a new (dwarf-linked) separated-debug file, that doesn't depend on DWO/DWP files. The three goals which you`ve described are our far goals. Indeed, the best solution would be to create valid optimized debug info without additional stages...

So I've been looking at a particular performance problem with LLVM's symbolizer due to the use of ThinLTO, split DWARF, and split DWARF inlining info. This combination has a couple of problems: 1) it means multiple CUs in a single DWO, which isn't well defined/specified, and best avoided - so I'm working on fixing that here (won't fix split DWARF+Full LTO) because we already don't use cross-CU references in the split units (because there's no supported way to express that in DWARF), so we clone/move any DIEs...