search for: gsplit

Hi! Quick question - do you know if recent commits could cause this error, or I should go to bisect/debug this? Do we have tests that check that -gsplit-dwarf succeeds (i.e. compile and link step work)? $ cat a.cc int foo(int x) { return x + 1; } int main() { return foo(42); } $ ./bin/clang++ -gsplit-dwarf a.cc /tmp/a-005b1a.o(.debug_pubnames+0x6): error: undefined reference to '.L.debug_info_begin0' clang-3.3: error: linker command...

So, after many shenanigans, we finally have -gmlt-like inline summary debug info in .debug_info when using -gsplit-dwarf (see r221306). Hooray \o/ Testing this with asan, it seems to be working: Given a simple example of inlining 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 fun...

Hello, I understand shared linked is currently a lot slower than static linked. However, for debug build, where speed is not required. Shared link has A lot of advantage. Static linked clang/llvm on linux is 17G, shared build is only 1.5G. On a mainstream linux host machine with 12G memory, only -j1 can be used to finish final linking step. With -j8 the linux will link the

...ay to massively reduce the amount of debug info going to the linker) >type units are mostly /just/ overhead in the .dwo files: since the debug info is not linked, there's no opportunity to remove the >duplication anyway (unless you're making a DWP - like a >dsym file) Yeah. Looks -gsplit-dwarf? and -fdebug-types-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). But then does it make sence to emit multiple .debug_info sections with -gs...

...wever, for debug build, where speed is not required. Shared link has A lot of advantage. Static linked clang/llvm on linux is 17G, shared build is only 1.5G. Assuming you're talking about a debug build, you can probably get that down a lot with at least -fdebug-types-section or with -gsplit-dwarf. On a mainstream linux host machine with 12G memory, only –j1 can be used to finish final linking step. If you use Ninja, I believe it has a separate pool limit you can tweak for linking (but, again, with -fdebug-types-section or -gsplit-dwarf, you might make the link steps more pal...

...t of debug info going to the linker) >>>type units are mostly /just/ overhead in the .dwo files: since the debug info is not linked, there's no opportunity to remove the >>>duplication anyway (unless you're making a DWP - like a >dsym file) >> >>Yeah. Looks -gsplit-dwarf​ and -fdebug-types-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 ( h...

Hello All. I must be missing the really obvious here: mm <- function(d, i) median(d[i]) b1 <- boot(gravity$g, mm, R = 1000) b1 b2 <- boot(gravity$g, mm, R = 1000, strata = gravity$series) b2 Both b1 and b2 seem to have done (almost) the same thing, but it looks like the strata argument in b2 has been ignored. However, str(b1) vs str(b2) does show that the strata have been noted

...ils. Issue appears when we start to provide .debug_str section to DWARF parser. And it is relative to following 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...

...broaden the surface to "disable if 32 bit and targeting gdb". -ggnu-pubnames makes gdb-index creation much more efficient by allowing gdb-index generation not to have to parse most of the DWARF DIEs, and just create the index straight from a table. (this is necessary for correctness in -gsplit-dwarf mode (where the DIEs are not available at link time as they're in the .dwo not the .o), and an efficiency gain otherwise) If "disable if 32 bit and targeting gdb" is overly broad (I feel it kind of is, but I'm not wedded to it) we could require those working around the gold...

On 08/16/2013 02:23 PM, David Chisnall wrote: > On 16 Aug 2013, at 22:01, reed kotler <rkotler at mips.com> wrote: > >> we used to be able to just make in the lib/target/Mips and then in llc and it was really fast. >> >> part of it is probably that we have all this debug information that we don't need because none of use are working on clang itself (well, almost

..."disable if 32 bit and targeting gdb". > > -ggnu-pubnames makes gdb-index creation much more efficient by allowing > gdb-index generation not to have to parse most of the DWARF DIEs, and just > create the index straight from a table. (this is necessary for correctness > in -gsplit-dwarf mode (where the DIEs are not available at link time as > they're in the .dwo not the .o), and an efficiency gain otherwise) > > If "disable if 32 bit and targeting gdb" is overly broad (I feel it kind > of is, but I'm not wedded to it) we could require those work...

...multiple .debug_info sections, split DWARF, thin lto. Following are size/performance results for the D74169: A: --function-sections --gc-sections B: --function-sections --gc-sections --gc-debuginfo C: --function-sections --gc-sections --fdebug-types-section D: --function-sections --gc-sections --gsplit-dwarf E: --function-sections --gc-sections --gc-debuginfo --compress-debug-sections=zlib LLVM code base: -------------------------------------------------------------- | Options | build time | bin size | lib size | -------------------------------------------------------------- |...

...39;d like to learn. -- adrian > As far as the .debug_names size goes, I should also point out that the > binary in question was built with -fno-limit-debug-info, which isn't a > default setup on linux. I have tried measuring the sizes without that > flag and with fission enabled (-gsplit-dwarf) and the results are: > without compression: > - clang binary: 960 MB > - .debug_names: 130 MB (13%) > - debug_pubnames: 175 MB (18%) > - debug_pubtypes: 204 MB (21%) > - median time for setting a breakpoint on non-existent function > (variance +/- 2%): > real 0m3.526s...

Hi, I've tagged 3.8.1-final, so testers can start building the final binaries. -Tom

...() { } __attribute__((always_inline)) void f2() { f1(); }; b.cpp: void f2(); void f3() { f2(); } c.cpp: void f3(); int main() { f3(); } $ clang++ {a,b}.cpp -g -c -emit-llvm -S $ llvm-link {a,b}.ll -S -o ab.ll $ clang++-tot c.cpp ab.ll -gsplit-dwarf $ dwp {c,ab}.dwo -o cab.dwp This produces two dwo files - one per object file (c.dwo, ab.dwo). If we look at the contents, they make a fair bit of sense: 0x0b: DW_TAG_compile_unit [1] * 0x19: DW_TAG_subprogram [2] 0x25: DW_TAG_subprogram [3] 0x31: DW_TAG_subprogram [4] 0x4...

Hi all ! We have an issue with LLD, it is "relocation R_X86_64_32 out of range" (PR31109) which occurs during resolving relocations in debug sections. It looks happens because .debug_info section can be too large sometimes and 32x relocation is not enough to represent the value. One of possible solutions looks to be to deduplicate information to reduce .debug_info size. The rest of

> On Jun 13, 2018, at 11:18 AM, Jonas Devlieghere via lldb-dev <lldb-dev at lists.llvm.org> wrote: > > Hi Pavel, > >> On Jun 13, 2018, at 6:56 AM, Pavel Labath <labath at google.com <mailto:labath at google.com>> wrote: >> >> Hello again, >> >> It's been nearly six months since my first email, so it's a good time >> to

...; >> void f3() { >> f2(); >> } >> c.cpp: >> void f3(); >> int main() { >> f3(); >> } >> $ clang++ {a,b}.cpp -g -c -emit-llvm -S >> $ llvm-link {a,b}.ll -S -o ab.ll >> $ clang++-tot c.cpp ab.ll -gsplit-dwarf >> $ dwp {c,ab}.dwo -o cab.dwp >> >> This produces two dwo files - one per object file (c.dwo, ab.dwo). If we look at the contents, they make a fair bit of sense: >> >> 0x0b: DW_TAG_compile_unit [1] * >> 0x19: DW_TAG_subprogram [2] >> 0x...

...h: cd /«PKGBUILDDIR»/build-llvm/lib/Support && /usr/bin/g++-6 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/«PKGBUILDDIR»/build-llvm/lib/Support -I/«PKGBUILDDIR»/lib/Support -I/«PKGBUILDDIR»/build-llvm/include -I/«PKGBUILDDIR»/include -std=c++0x -gsplit-dwarf -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment -std=c++11 -ffunction-sections -fdata-sections -O2 -g -DNDEBUG -fno-exceptions...

L.S., I'm currently in the process of creating Debian packages for clang/llvm release 3.9.0. For this I'm using the steps as explained on 'http://apt.llvm.org/building-pkgs.php'. Up until now I have done: $ debcheckout svn://anonscm.debian.org/svn/pkg-llvm/llvm-toolchain/ $ cd llvm-toolchain/branches $ sh 3.9/debian/orig-tar.sh RELEASE_390 final Now, as is explained, I would