[lldb-dev] lldb-instr not working

Hi, I've recently tried to use lldb-instr, as mentioned in https://lldb.llvm.org/resources/sbapi.html, but I'm having the following issue when running it on darwin. ./lldb-instr > LLVM ERROR: Unable to find target for this triple (no targets are registered) Is this a known issue? Or should lldb-i

[lldb-dev] RFC: Processor Trace Support in LLDB

Hi all, Here I propose, along with Greg Clayton, Processor Trace support for LLDB. I’m attaching a link to the document that contains this proposal if that’s easier to read for you: https://docs.google.com/document/d/1cOVTGp1sL_HBXjP9eB7qjVtDNr5xnuZvUUtv43G5eVI/edit#heading=h.t5mblb9ugv8f

Re: [lldb-dev] RFC: Processor Trace Support in LLDB

is executed, or you could have an annotated CFG view. Yes! This becomes highly important, especially if there's timing information associated. You could make visualizations over time, with callstacks, statistics, etc. My intention is to eventually flesh out those cool features. Thanks, - Walte

Re: [lldb-dev] RFC: Processor Trace Support in LLDB

r/why". > > Thanks so much for starting this and looking forward to the work and > collaboration. > > -eric > > On Thu, Sep 17, 2020 at 8:28 PM Walter via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> Hi all, >> >> >> >> Here I propose,

Re: [lldb-dev] RFC: Processor Trace Support in LLDB

; > For unit tests, a json format tracing record is probably convenient, but > for practical usage we may need a compacter format, e.g. Cap'n Proto > used by rr > (https://robert.ocallahan.org/2017/08/stabilizing-rr-trace-format.html) > Hope the framework can be easily adapte

Re: [lldb-dev] RFC: Processor Trace Support in LLDB

mmand. What do you think? > > The main place where this idea breaks down is the multi-process traces. > While we could certainly make "target create --trace" create multiple > targets, that would be fairly unusual. OTOH, the whole concept of having > multiple targets share somet

Re: [lldb-dev] RFC: Processor Trace Support in LLDB

n't available we will not be able to dump anything. But I would like to > see process/thread commands for this scenario: > > - process trace start/stop (only succeeds if we can gather trace data > through the process plug-in) > - thread trace start/stop (which can succeed only