similar to: [LLVMdev] gsplit-dwarf broken on Linux?

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

?Hi ! I have a question about code used for collecting ranges. I was trying to fix PR35199. Its issue that it calls unreachable when calls DWARFObject::getFileName(). We do not implement this method in LLD and it fails. Issue appears when we start to provide .debug_str section to DWARF parser. And it is relative to following code (lines 335-339):

>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

>*nod* That's been the historic ELF+DWARF approach, but both MacOS (with dsyms+DWARF) and Windows >(COFF+CodeView+PDB) don't do it that way, and instead involve the linker to a degree. >Mostly I'm wondering if it'd be reasonable 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

On Wed, May 3, 2017 at 2:09 PM Adrian Prantl <aprantl at apple.com> wrote: > > > On May 3, 2017, at 2:00 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > 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

> On May 3, 2017, at 7:43 PM, Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On May 3, 2017, at 2:59 PM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote: >> >> >> >> On Wed, May 3, 2017 at 2:09 PM Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote:

Hi James, Thank you for the comments. >I think we're not terribly far from 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

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 have multiple

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

On Fri, Mar 4, 2016 at 5:50 PM, Yuanfeng Peng <yuanfeng.jack.peng at gmail.com> wrote: > Hi Jingyue, > > My name is Yuanfeng Peng, I'm a PhD student at UPenn. I'm sorry to bother > you, but I'm having trouble with gpucc in my project, and I would be really > grateful for your help! > > Currently we're trying to instrument CUDA code using LLVM 3.9, and

Hey Jingyue, Thanks for being so responsive! I finally figured out a way to resolve the issue: all I have to do is to use `-only-needed` when merging the device bitcodes with llvm-link. However, since we actually need to instrument the host code as well, I encountered another issue when I tried to glue the instrumented host code and fatbin together. When I only instrumented the device code, I

Hi Jingyue, Sorry to ask again, but how exactly could I glue the fatbin with the instrumented host code? Or does it mean we actually cannot instrument both the host & device code at the same time? Thanks! yuanfeng On Tue, Mar 15, 2016 at 10:09 AM, Jingyue Wu <jingyue at google.com> wrote: > Including fatbin into host code should be done in frontend. > > On Mon, Mar 14, 2016

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

You are right. Thanks! I fixed that one as well as some other issues. I built LLVM-8 with Debug + no-rtti. But it now has the following error: Stack dump: 0. Program arguments: clang-8 -cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -disable-free -main-file-name time-1.7.c -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases

I have managed to compile llvm and clang against musl, but it behaves really strange: At first I tried to launch the compiler with musl dynamic loader: $ LD_LIBRARY_PATH=/path/to/musl/lib /path/to/musl/lib/ld-musl-x86_64.so.1 /path/to/llvm/bin/clang -v clang version 4.0.0 (https://github.com/llvm-mirror/clang 40adebeca0f99006d407508653c2cbd270a1a51c) (https://github.com/llvm-mirror/llvm

llvm[1]: Compiling APFloat.cpp for Release+Asserts build clang: TargetInfo.cpp:1778: llvm::Type *GetX86_64ByValArgumentPair(llvm::Type *, llvm::Type *, const llvm::TargetData &): Assertion `Lo->isIntegerTy() && "Invalid/unknown lo type"' failed. 0 clang 0x0000000001c132ef 1 clang 0x0000000001c13804 2 libpthread.so.0 0x00002ba7d7eaec60 3

Dear lazydev, I'm writing an instrumentation pass that depends on AliasAnalysis. My getAnalysisUsage() looks as follows: 2453 void ThreadSanitizer::getAnalysisUsage(AnalysisUsage &AU) const { 2454 AU.addRequired<TargetData>(); 2455 AU.addRequired<AliasAnalysis>(); 2456 } and the pass initialization: 2668 char ThreadSanitizer::ID = 0; 2669

Hi Justin, Thanks for your response! The clang & llvm I'm using was built from source. Below is the output of compiling with -v. Any suggestions would be appreciated! *clang version 3.9.0 (trunk 270145) (llvm/trunk 270133)* *Target: x86_64-unknown-linux-gnu* *Thread model: posix* *InstalledDir: /usr/local/bin* *Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8*

Hi, I am trying to compile a simple program with Clang 3.3 on Linux and used -pg and -O2 option. The program would crash with segfault. Interestingly if I compile it with -pg option only it works. Do you have any idea why it crashes? And any workaround? $ cat myprog.c int main() { return 0; } $ clang -v -pg -O2 myprog.c clang version 3.3 (tags/RELEASE_33/final) Target:

Hi,   We propose llvm-dwarfutil - a dsymutil-like tool for ELF.   Any thoughts on this?   Thanks in advance, Alexey. ====================================================================== llvm-dwarfutil(Apndx A) - is a tool that is used for processing debug info(DWARF) located in built binary files to improve debug info quality, reduce debug info size and accelerate debug info processing.