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

[Walter via lldb-dev]

Thanks for your feedback Fangrui, I've just been checking Capn' Proto and
it looks really good. I'll keep it in mind in the design and see how it can
optimize the overall data transfer.

- Walter

Il giorno dom 20 set 2020 alle ore 11:24 Fangrui Song 
ha scritto:

> On 2020-09-18, Eric Christopher via lldb-dev wrote:
> >Hi Walter,
> >
> >I've only done a brief scan of the document but, in general, I'm favorable
> >of the goals, aim, and approach. Something I think would be good would be
> >to compare/contrast against rr as an "exploring alternatives" section of
> >the document. I think the document should also be made available/adapted
> to
> >be part of the documentation on "why lldb is implementing this
> feature/what
> >it can be used for/why".
> >
> >Thanks so much for starting this and looking forward to the work and
> >collaboration.
> >
> >-eric
>
> Same. I am really excited that this work will open up possibilities for
> reverse debugging, which is the most important factor impeding me from
> migrating (from gdb) to 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 adapted to such a compact format.
>
> >On Thu, Sep 17, 2020 at 8:28 PM Walter via lldb-dev <
> lldb-dev@lists.llvm.org>
> >wrote:
> >
> >> 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
> <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1cOVTGp1sL-5FHBXjP9eB7qjVtDNr5xnuZvUUtv43G5eVI_edit-23heading-3Dh.t5mblb9ugv8f=DwMGaQ=5VD0RTtNlTh3ycd41b3MUw=erxV6KMIZvIQjyWYW8YpOiKz-WqJt4giKQA34YMHsRY=DuuwXHUQJpW4TcCay4hPsBund-eBI2uVaVimqEPsp5k=o6vqoYYbn-Tz_d34hoLJvWhEnnhracOO6yDsMzq8wR0=>.
> Please make any comments in this mail list.
> >>
> >>
> >>
> >> If you want to quickly know what Processor Trace can do, you can read
> this https://easyperf.net/blog/2019/08/23/Intel-Processor-Trace <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__easyperf.net_blog_2019_08_23_Intel-2DProcessor-2DTrace=DwMGaQ=5VD0RTtNlTh3ycd41b3MUw=erxV6KMIZvIQjyWYW8YpOiKz-WqJt4giKQA34YMHsRY=DuuwXHUQJpW4TcCay4hPsBund-eBI2uVaVimqEPsp5k=iaErHaf8byXlZb1YFUk0BpQ-duMhNouUUMyktLm3soQ=
> >.
> >>
> >>
> >>
> >> Any comments are appreciated, especially the ones regarding the
> commands the user will interact with.
> >>
> >>
> >>
> >> Thanks,
> >>
> >> Walter Erquinigo.
> >>
> >>
> >>
> >>
> >>
> >> # RFC: Processor Trace Support in LLDB
> >>
> >>
> >>
> >>
> >>
> >> # What is processor tracing?
> >>
> >>
> >>
> >> Processor tracing works by capturing information about the execution of
> a process so that the control flow of the program can be reconstructed
> later. Implementations of this are Intel Processor Trace for X86, x86_64 ([
> https://software.intel.com/content/www/us/en/develop/blogs/processor-tracing.html](https://software.intel.com/content/www/us/en/develop/blogs/processor-tracing.html))
> and ARM CoreSight for some ARM devices ([
> https://developer.arm.com/ip-products/system-ip/coresight-debug-and-trace](https://developer.arm.com/ip-products/system-ip/coresight-debug-and-trace)
> ).
> >>
> >>
> >>
> >> As a clarifying example, with these technologies it’s possible to trace
> all the threads of a process, and after the process has finished,
> reconstruct every single instruction address each thread has executed. This
> could include some additional information like timestamps, async CPU
> events, kernel instructions, bus clock ratio changes, etc. On the other
> hand, memory and registers are not traced as a way to limit the size of the
> trace.
> >>
> >>
> >>
> >>
> >>
> >> # Intel Processor Trace as the first implementation
> >>
> >>
> >>
> >> We’ll focus on Intel Processor Trace (Intel PT), but in a generic way
> so that in the future similar technologies can be onboarded in LLDB.
> >>
> >>
> >>
> >> Intel PT has the following features:
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> *   Control flow tracing in a highly encoded format
> >>
> >> *   3% to 5% slowdown when capturing
> >>
> >> *   No memory nor registers captured
> >>
> >> *   Kernel tracing support
> >>
> >> *   Timestamps of branches are produced, which can be used for profiling
> >>
> >> *   Adjustable size of trace buffer
> >>
> >> *   Supported on most Intel CPUs since 2015
> >>
> >> *   X86 and x86_64 only
> >>
> >> *   Official support only on Linux
> >>
> >> *   Basic support on Windows
> >>
> >> *   Decoding/analysis can be done on any operating system
> >>
> >>
> >>
> >> A very nice introduction to Intel PT can be found [
> 

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

[Walter via lldb-dev]

Hi Eric, thanks for the feedback
> Something I think would be good would be to compare/contrast against rr
as an "exploring alternatives" section of the document.

I'll include that. I've done some comparative research on rr and I think I
can provide valuable input.

> I think the document should also be made available/adapted to be part of
the documentation on "why lldb is implementing this feature/what it can be
used for/why".

I think this information is scattered throughout the document, but I'll
make sure to answer this in one of the first paragraphs.

Thanks!
- Walter

Il giorno ven 18 set 2020 alle ore 19:58 Eric Christopher <
echri...@gmail.com> ha scritto:

> Hi Walter,
>
> I've only done a brief scan of the document but, in general, I'm favorable
> of the goals, aim, and approach. Something I think would be good would be
> to compare/contrast against rr as an "exploring alternatives" section of
> the document. I think the document should also be made available/adapted to
> be part of the documentation on "why lldb is implementing this feature/what
> it can be used for/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, 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
>>  
>> .
>>  Please make any comments in this mail list.
>>
>>
>>
>> If you want to quickly know what Processor Trace can do, you can read this 
>> https://easyperf.net/blog/2019/08/23/Intel-Processor-Trace 
>> .
>>
>>
>>
>> Any comments are appreciated, especially the ones regarding the commands the 
>> user will interact with.
>>
>>
>>
>> Thanks,
>>
>> Walter Erquinigo.
>>
>>
>>
>>
>>
>> # RFC: Processor Trace Support in LLDB
>>
>>
>>
>>
>>
>> # What is processor tracing?
>>
>>
>>
>> Processor tracing works by capturing information about the execution of a 
>> process so that the control flow of the program can be reconstructed later. 
>> Implementations of this are Intel Processor Trace for X86, x86_64 
>> ([https://software.intel.com/content/www/us/en/develop/blogs/processor-tracing.html](https://software.intel.com/content/www/us/en/develop/blogs/processor-tracing.html))
>>  and ARM CoreSight for some ARM devices 
>> ([https://developer.arm.com/ip-products/system-ip/coresight-debug-and-trace](https://developer.arm.com/ip-products/system-ip/coresight-debug-and-trace)).
>>
>>
>>
>> As a clarifying example, with these technologies it’s possible to trace all 
>> the threads of a process, and after the process has finished, reconstruct 
>> every single instruction address each thread has executed. This could 
>> include some additional information like timestamps, async CPU events, 
>> kernel instructions, bus clock ratio changes, etc. On the other hand, memory 
>> and registers are not traced as a way to limit the size of the trace.
>>
>>
>>
>>
>>
>> # Intel Processor Trace as the first implementation
>>
>>
>>
>> We’ll focus on Intel Processor Trace (Intel PT), but in a generic way so 
>> that in the future similar technologies can be onboarded in LLDB.
>>
>>
>>
>> Intel PT has the following features:
>>
>>
>>
>>
>>
>>
>>
>> *   Control flow tracing in a highly encoded format
>>
>> *   3% to 5% slowdown when capturing
>>
>> *   No memory nor registers captured
>>
>> *   Kernel tracing support
>>
>> *   Timestamps of branches are produced, which can be used for profiling
>>
>> *   Adjustable size of trace buffer
>>
>> *   Supported on most Intel CPUs since 2015
>>
>> *   X86 and x86_64 only
>>
>> *   Official support only on Linux
>>
>> *   Basic support on Windows
>>
>> *   Decoding/analysis can be done on any operating system
>>
>>
>>
>> A very nice introduction to Intel PT can be found 
>> [https://software.intel.com/content/www/us/en/develop/blogs/processor-tracing.html](https://software.intel.com/content/www/us/en/develop/blogs/processor-tracing.html)
>>  and 
>> [https://easyperf.net/blog/2019/08/23/Intel-Processor-Trace](https://easyperf.net/blog/2019/08/23/Intel-Processor-Trace).
>>  Totally recommended to fully grasp the impact of 

[lldb-dev] LLDB got SIGCHLD on hitting the breakpoint

[le wang via lldb-dev]

Hello,everyone:
I've got a problem, when debugging my process with lldb tool on linux
OS(CentOS7).While I use lldb command to set breakpoints, and launch my
process, my process will execute a binary code which contains debug
information, but when my process launched, all breakpoints can not be hit,
The debug process and several received informations like below:
（lldb）target create  /home/out/lib/linux64/Debug/appEngine
Current executable set to '/home/out/lib/linux64/Debug/appEngine'  (x86_64)

（lldb）br s -f /home/out/lib/linux64/Debug/configDB/TestFunctionProcess.cpp
-l1
Breakpoint 1: no locations(pending).
WARNING :  Unable to resolve breakpoint to any actual locations.
（lldb）br s -f /home/out/lib/linux64/Debug/configDB/TestFunctionProcess.cpp
-l2
Breakpoint 2: no locations(pending).
WARNING :  Unable to resolve breakpoint to any actual locations.
（lldb）r
Process 4256 launched: '/home/out/lib/linux64/Debug/appEngine'  (x86_64)

Process 4256 stopped and restarted: thread1 received signal:   SIGCHLD
Process 4256 stopped and restarted: thread1 received signal:   SIGCHLD
Process 4256 stopped and restarted: thread1 received signal:   SIGCHLD
Process 4256 stopped and restarted: thread1 received signal:   SIGCHLD
Process 4256 stopped and restarted: thread1 received signal:   SIGCHLD
Process 4256 stopped and restarted: thread2 received signal:   SIGCHLD

Process stopped and restarted: thread 2 received signal: SIGCHLD
It seems these repeated restart notifications come from lldb, and at last
although my process is executed,  it is meaningless. I have checked that
debug information in IR is correct. I have no idea the reason. Can anyone
tell me the reason and how to fix this problem. My lldb version is 5.0.0,
which got from http://www.llvm.org/ with llvm5.0.0


Thanks,
le wang
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev