similar to: Slow debugger starts of LLVM tools

David Jones via llvm-dev <llvm-dev at lists.llvm.org> writes: > GDB likes to load all symbols from shared libraries up front. And on > x86_64 your main executable is really just another shared library. Yes, but does gdb reload everything on each execution? Every time I execute "run" I see the same slow behavior. Loading the symbols for small tools like llvm-rc takes

This is admittedly a longshot, but Can you check whether you experience unusually long run times with LLDB? If there’s something strange about tge binaries we generate, maybe lldb will exhibit some strangeness too and we can more easily profile it. On Wed, Jan 9, 2019 at 2:48 PM Shoaib Meenai via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I don't know about the issues with

Yep, as others have mentioned - using a linker-generated gdb-index is super helpful (10s for my machine to start debugging an unoptimized clang, set a breakpoint at llvm::StringRef::StringRef and run until that breakpoint is hit, as opposed to 1m26s without an index) That's also with/without split DWARF too, but I suspect most of the benefit is in the index there. Split DWARF might save you

On Thu, Aug 4, 2016 at 9:44 AM Joerg Sonnenberger via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Mon, Aug 01, 2016 at 04:47:49AM +0000, Chandler Carruth via llvm-dev > wrote: > > Chris added alloca merging in the inliner a looooong time ago, 2009. The > > reason he added it was because at the time we didn't do stack coloring > and > > without it we had

Hallo, LLVMdev! I have found you in LLVM Developers page (http://llvm.org/developers.cgi). First thank you for all of your work with LLVM. About: I work with the LLVM Compiler Infrastructure to implement a backend for specific processor xPEC of chip NetX (http://hilscher.com/netx.html). So C-code already possible compile to the native xPEC assembly code (works perfect! LLWM a big

Something seems to have changed with the debugger option since I used it last, unless I've forgotten something really stupid (much more likely) . The debugger doesn't seem to recognise the names of C routines ***************** [jonm at localhost jonm]$ cat test.c #include "S.h" void test(int *x,int *y){ y[0]=x[0]+2; } [jonm at localhost jonm]$ R COMPILE test.c gcc

> -----Original Message----- > From: Daniel Berlin [mailto:dberlin at dberlin.org] > Sent: Friday, May 01, 2015 3:15 PM > To: Robinson, Paul > Cc: cfe-dev at cs.uiuc.edu Developers (cfe-dev at cs.uiuc.edu); LLVM Developers > Mailing List (llvmdev at cs.uiuc.edu); lldb-dev at cs.uiuc.edu > Subject: Re: [LLVMdev] What does "debugger tuning" mean? > > On Fri, May

This is the rsync version I am using. rsync version 2.5.5 protocol version 26 Copyright (C) 1996-2002 by Andrew Tridgell and others <http://rsync.samba.org/> Capabilities: 64-bit files, socketpairs, hard links, symlinks, batchfiles, IPv6, 64-bit system inums, 64-bit internal inums I have a file with a looooong name which I rsync from PC1 to PC2. (redhat-9) I am getting the

> On May 1, 2015, at 2:18 PM, Greg Clayton <gclayton at apple.com> wrote: > > >> On May 1, 2015, at 2:00 PM, Robinson, Paul <Paul_Robinson at playstation.sony.com> wrote: >> >>> A few more things that vote for debugger tuning: >>> >>> - LLDB doesn't like to have DWARF that has a class A that inherits from >>> class B, but

> On May 5, 2015, at 8:12 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Tue, May 5, 2015 at 4:04 PM, Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote: > > > On May 1, 2015, at 2:18 PM, Greg Clayton <gclayton at apple.com <mailto:gclayton at apple.com>> wrote: > > > > > >> On May 1,

Hi I am looking at open projects that LLVM want to implement and it seems to be a suggestion to write an LLVM IR level debugger. Is there any existing LLVM projects out there that already does such a thing? If not, I would like to try implementing one myself. By debugger, I think it means something like gdb, where you can insert breakpoints, run code and observe layout of registers and memory at

This is basically a reboot of the previous thread titled About the "debugger target" except that "target" was really too strong a term for what I had intended to use this feature for. "Debugger tuning" is more like it. You don't need to have read the previous thread, I'll recap here. Fundamentally, Clang/LLVM uses DWARF as the specification for the

I think I am whistling in the wind, but is there a modern symbolic debugger for R programmes? I am working through some one else's code, thousands of lines, that has the occasional bug in it, and a lot in my understanding of it. I cannot make setBreakpoint or findLineNum work. I get "No source refs found.". I am starting to loose my mind! A debugger where I could set

You can attach debug info to the Llvm module about LLVM IR, at which point one can throw the executable into any debugger and get llvm level debugging. I've started a patch to revive this feature (DebugIR pass). I've been sidetracked the past month, but I'll come back to it soon :) https://reviews.llvm.org/D40778 Cheers, Siddharth On Thu 4 Jan, 2018, 09:23 Brenda So via llvm-dev,

Another example would be .debug_pubnames and .debug_pubtypes sections. Currently these default to omitted for Darwin and PS4, but included everywhere else. My initial patch for "tuning" changes the PS4 platform criterion to the SCE debugger predicate; quite likely the "not Darwin" criterion ought to be "not LLDB" or in other words "on for GDB only."

> A few more things that vote for debugger tuning: > > - LLDB doesn't like to have DWARF that has a class A that inherits from > class B, but only a forward declaration of class B is provided. Hmm do we emit that kind of thing today? In a naïve test, I'm seeing the full description of class B. > - LLDB wants the .apple_XXX accelerator tables, GDB wants >

While I've already posted reviews for the initial patches for this (see http://reviews.llvm.org/D8506 and http://reviews.llvm.org/D8599), the grapevine suggests I should post a lengthier description of my intent for the "debugger target." The idea was prompted by a suggestion from Eric Christopher, and I'm running with it. Various bits of the DWARF we produce are conditional on

I just skimmed through the thread again, and I *think* all the main questions have been answered… It feels like the consensus is "reluctant agreement," with the specific design points being: - a "debugger tuning" option would have some sort of target-based default - the "debugger tuning" option would unpack into defaults for individual feature flags -

I did a standard install of R on Fedora 13 using yum as root, which I assumed installed both the base packages and the devel packages needed to install R Commander (there weren't any optional packages listed on the yum info page). My version of R is updated to the latest 2.11 version. But, running install.packages("Rcmdr", dependencies=TRUE) as root, within R produces the following

Hi, All: I had some trouble debugging C source dynamically loaded into R , when I issued N in gdb(or insight) , the debugger, instead of moving downward step by step, jumped to strange positions (upward, downward, one step, a few steps away). To enter the debugger, I issued gdb(insight) Rgui.exe in Cygwin and add this line : asm("int $3"); to my C code. After entering R, I