similar to: [LLVMdev] New LLDB Debugger

> 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

In some cases we do want to make the decision based on the target. For Hexagon, we don't support GDB anymore, only LLDB, so we always want LLDB tuning. The clang driver should have a way to specify that. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -----Original Message----- From:

> 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,

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 don’t think there was a driver patch so far, was there? -- adrian > On May 6, 2015, at 1:19 PM, Eric Christopher <echristo at gmail.com> wrote: > > Does the patch do all of this? > > -eric > > On Wed, May 6, 2015 at 1:18 PM Robinson, Paul <Paul_Robinson at playstation.sony.com <mailto:Paul_Robinson at playstation.sony.com>> wrote: > I just skimmed

Comments on the patch raise the following questions, probably better discussed here. First: Should LLVM default to "no tuning" rather than a target-specific default? There are two natural follow-up questions: What would "no tuning" actually mean? Where would the target-specific defaulting occur? I originally came down against the "no tuning" option, in favor of the

> 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

It is interesting that the stop reason on the thread that stopped is "trace". That's what you would expect returning from the single-step to step over the breakpoint. But it looks like we got a signal while single-stepping, but the stop reason was misreported by somebody. Jim > On Apr 17, 2018, at 6:00 AM, Pavel Labath via lldb-dev <lldb-dev at lists.llvm.org> wrote:

Hi All, > I think this ignores the real problem with the MCJIT debugging interface: it doesn't give MCJIT clients any way of directly accessing and parsing the debug metadata. Sorry - it wasn't clear from my original post, but I'm hoping to improve debugging APIs in general, not just for the system debugger. I think there are two orthogonal concerns here - (1) the debug info

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

[+lldb-dev] Hello Steve, thanks for the report. The fact that you see the rendezvous breakpoint being hit many times is not surprising. We get those every time the library is loaded (we need that to load relevant debug info and set potential breakpoints). However, they should generally not be surfaced to the user (unless you have the stop-on-sharedlibrary-events setting set, which you

Thanks for the suggestions but it doesn't appear to be working correctly for me. I tried building the below after seeing the results with "clang -g -std=c99 test.c" and got the same result LLDB thinks MyArray is 81 elements long even though 81 and 80 doesn't show up anywhere in the llvm-ir (I tried again using an llvm ir file made by clang -g -std=c99 test.c -S -emit-llvm and

On Sun, Aug 10, 2014 at 3:37 PM, Filip Pizlo <fpizlo at apple.com> wrote: > > >> On Aug 10, 2014, at 3:07 PM, Eric Christopher <echristo at gmail.com> wrote: >> >>> On Sun, Aug 10, 2014 at 1:43 PM, Filip Pizlo <fpizlo at apple.com> wrote: >>> I think this ignores the real problem with the MCJIT debugging interface: it doesn't give MCJIT

Hello lldb developers, I am running into a problem with lldb on Linux. I am currently running llvm 6.0.0. I have an executable that dynamically loads a large number of shared libraries at runtime. These are explicitly loaded via dlopen (they are specified in a configuration file), and after loading a few (typically a dozen or so, but the number varies) lldb will halt during dlopen. If I

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

Thanks Simon. I'll probably just switch to rocker when needing to debug in that case. THK On Tue, Apr 21, 2020 at 6:51 PM Simon Urbanek <simon.urbanek at r-project.org> wrote: > Tim, > > as a security precaution Apple has disabled the ability to debug notarized > applications*. It means any software distributed on macOS Catalina (and > they may have retro-actively

On Fri, Mar 2, 2018 at 3:58 PM, Roman Popov via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi all, > > As you may know modern C++ debuggers (GDB and LLDB) support dynamic type > identification for polymorphic objects, by utilizing C++ RTTI. > Unfortunately this feature does not work with Clang and GDB >= 7.x . The > last compiler that worked well was G++ 6.x >

-lldb-dev, +llvm-dev lldb-dev is specifically for the llvm debugger, and llvm-dev is for everything else (including lld) Did you compile the object files with clang and use -mllvm -emit-codeview-ghash-section? It sounds like probably not. If you don’t do that /DEBUG:GHASH will indeed be much slower. I wonder if we should emit a linker diagnostic in this case On Fri, Jan 19, 2018 at 12:09 PM

I see: Tims-Air:~ tkeitt$ R --version R version 3.6.3 (2020-02-29) -- "Holding the Windsock" Copyright (C) 2020 The R Foundation for Statistical Computing Platform: x86_64-apple-darwin15.6.0 (64-bit) R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under the terms of the GNU General Public License versions 2 or 3. For more information