similar to: RFC: libtrace

no expression parser or knowledge of any specific programming language. Basically I just mean that the parsing of the native DWARF format itself is in scope, but anything beyond that is out of scope. For symbolication we have things like llvm-symbolizer that already just work and are built on top of LLVM's dwarf parsing code. Similarly, LLDB's type system could be built on top of it as

You'd probably need to pull the Unwinder in if you want backtraces, but that part shouldn't be that hard to disentangle. I don't think you'd need much else? Basing your work on NativeProcess rather than lldb proper would also cut the number of observer processes in half and avoid the context switches between the server and the debugger. That seems more appropriate for a

On Tue, Jun 26, 2018 at 1:28 PM Adrian Prantl <aprantl at apple.com> wrote: > > > > On Jun 26, 2018, at 11:58 AM, Zachary Turner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Hi all, > > > > We have been thinking internally about a lightweight llvm-based > ptracer. To address one question up front: the primary way in which this

On Wed, 27 Jun 2018 at 01:14, Zachary Turner via lldb-dev <lldb-dev at lists.llvm.org> wrote: > > Yes that’s what I’ve been thinking about as well. > > One thing I’ve been giving a lot of thought to is whether to serialize the handling of trace events. I want to balance the “this is a library and you should be able to get it to work for you no matter what your use case is”

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

Hi all, I think we've reached a state where we're ready to enable debug entry value production by default for the x86_64, ARM, and AArch64 targets. For context, this is a debug info feature that allows debuggers to recover the value of unmodified optimized-out parameters by 'going up' a stack frame and interpreting spilled values, constants, etc. to work out what was passed to the

Adrian, Thanks for a quick reply! On Thu, Mar 22, 2018 at 4:22 PM, Adrian Prantl <aprantl at apple.com> wrote: > > >> On Mar 22, 2018, at 4:08 PM, Roman Levenstein <romixlev at gmail.com> wrote: >> >> Hi, >> >> I'm trying to achieve the following: >> >> - I have a global variable BaseAddress that holds the base address of >> a

On 16/12/2019 23:47, David Blaikie via llvm-dev wrote: > > > On Mon, Dec 16, 2019 at 2:40 PM Jonas Devlieghere <jonas at devlieghere.com > <mailto:jonas at devlieghere.com>> wrote: > > Hey James, > > This sounds really interesting. A few things that come to mind: > >  - I'm curious what kind of errors you'd be okay with in dump

Hey James, This sounds really interesting. A few things that come to mind: - I'm curious what kind of errors you'd be okay with in dump mode but not in consumer mode. From LLDB's perspective, we probably want to extract as much information as possible from a malformed line table, as long as we don't end up lying of course. - I need to take another look at the code, but

Yep, TAG_call_site_parameter and its children shouldn't require any extra relocations. Thanks! vedant > On Feb 7, 2020, at 2:01 PM, David Blaikie <dblaikie at gmail.com> wrote: > > For that sort of small growth, if it doesn't add more relocations (I think the call sites need them (but they're already emitted/that's not what we're discussing enabling here), but

> On Mar 22, 2018, at 4:47 PM, Roman Levenstein <romixlev at gmail.com> wrote: > > Adrian, > > Thanks for a quick reply! > > On Thu, Mar 22, 2018 at 4:22 PM, Adrian Prantl <aprantl at apple.com> wrote: >> >> >>> On Mar 22, 2018, at 4:08 PM, Roman Levenstein <romixlev at gmail.com> wrote: >>> >>> Hi, >>>

On Thu, Mar 22, 2018 at 4:51 PM, Adrian Prantl <aprantl at apple.com> wrote: > > >> On Mar 22, 2018, at 4:47 PM, Roman Levenstein <romixlev at gmail.com> wrote: >> >> Adrian, >> >> Thanks for a quick reply! >> >> On Thu, Mar 22, 2018 at 4:22 PM, Adrian Prantl <aprantl at apple.com> wrote: >>> >>> >>>>

The actual DWARF emission for call site parameters is gated inside of DwarfDebug::constructCallSiteEntryDIEs by `tuneForGDB() || tuneForLLDB()`. However, we are creating+updating CallSiteInfo (basically, in-memory only bookkeeping used by the backend to keep track of call sites) even when the debugger tuning is set to the Sony debugger. If this creates problems, feel free to file a bug and

Hi, Thanks you all for the collaboration! :) Paul, > This is not how tuning-controlled features are supposed to work. I will comment on the review. I see, I am working on addressing the comments from the [1]. I will update the diff asap. Thanks. Vedant, There are no entry values generated at -O0 level, but I will add a test case for it. Thanks. Best regards, Djordje On 8.2.20. 02:41,

Hi Eric & Orlando, It’s great to see interest in a lot of different aspects of debug info. At the same time, I’m concerned about a risk to making the topic so broad that we don’t have time to get through all the things people want to get through. I’m thinking there’s a different way to slice the topics, hopefully without much overlap, but that will allow a bit more focus. No doubt a lot of

Hello DWARF fans, I've just posted a set of four refactoring patches for DebugInfo/DWARF, which move in the direction of handling DWARF v4 or v5 type units and compile units more coherently. In DWARF v4, type units and compile units are strictly segregated into the .debug_types and .debug_info sections, respectively. This division was pretty ingrained into how DebugInfo/DWARF handled the

In short: Perhaps we should switch lld to the bfd-style tombstoning behavior for a release or two, letting users opt-in to testing with the new -1/-2 tombstoning in the interim, before switching to the new tombstone by default (while still having the flag to switch back when users find surprise places that can't handle the new behavior). In long: https://reviews.llvm.org/D81784 and follow-on

On Fri, Nov 15, 2019 at 8:07 AM Robinson, Paul <paul.robinson at sony.com> wrote: > | Any ideas why it wouldn't be more general to handle cases where the > variable isn't named? > > > > Couldn’t there be a DIE (flagged as artificial) to describe the > return-value temp? > There could be - though there are very few (the array bound example Adrian gave is the

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