Re: [lldb-dev] Inquiry for performance monitors

Hi Everyone I have developed a tool that facilitates lldb users using Intel(R) Processor Trace technology for debugging applications (as per discussions in this thread). The patch is https://reviews.llvm.org/D33035. Some highlights of this tool are: 1. The tool is built on top of lldb. It is not

Re: [lldb-dev] Loadable Code Segment Information & SectionType in LLDB

Hi Greg My comments are inlined: On Tue, Aug 9, 2016 at 7:01 PM, Greg Clayton wrote: > > > On Aug 9, 2016, at 9:01 AM, Abhishek Aggarwal via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > Hello all > > > > I have following 2 queries: > >

[lldb-dev] Loadable Code Segment Information & SectionType in LLDB

Hello all I have following 2 queries: 1. Can SB APIs of LLDB provide information regarding the loadable *Code Segment* (r-xp part of /proc/$PID/maps file in case of Linux) of a debugged process? The information I am looking for is start address and end address of the loadable code segment of the

[lldb-dev] Stop IDs for individual thread

Hi everyone While debugging an inferior with LLDB, for every stop event a new StopID is generated and this ID can be extracted from SBProcess::GetStopID() API. This ID indicates change in the state of the process between two stop events. As per my knowledge, in case of a multithreaded process thi

[lldb-dev] Developing a Plugin to be loaded in LLDB from external shared libs

Hi everyone There has been previous discussions in this mailing list regarding *E**nabling Intel(R) Processor Trace collection in LLDB. A new APIs are being developed to be added to SB APIs that will provide raw traces (collected on lldb-server side). These APIs are Trace technology independent an

Re: [lldb-dev] Development of a Plugin to be loaded in LLDB from external library

Hi Greg My comments are inlined. On Tue, Apr 26, 2016 at 7:03 PM, Greg Clayton wrote: > > > On Apr 26, 2016, at 1:50 AM, Abhishek Aggarwal via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > Hi everyone > > > > There has been previous discussions

[lldb-dev] Development of a Plugin to be loaded in LLDB from external library

Hi everyone There has been previous discussions in this mailing list regarding *E**nabling Intel(R) Processor Trace collection in LLDB. A new APIs are being developed to be added to SB APIs that will provide raw traces (collected on lldb-server side). These APIs are Trace technology independent an

Re: [lldb-dev] Inquiry for performance monitors

Hi Greg Please find any answers/queries inlined: On Thu, Feb 4, 2016 at 9:58 PM, Greg Clayton via lldb-dev < lldb-dev@lists.llvm.org> wrote: > >> On Feb 4, 2016, at 2:24 AM, Pavel Labath via lldb-dev < lldb-dev@lists.llvm.org> wrote: >> >> On 4 February 2016 at 10:04, Ravitheja Addepally >> wrot

Re: [lldb-dev] Inquiry for performance monitors

Hello Pavel As per my understanding, instead of doing it by expression evaluation if the code (to enable pt and gathering the raw traces) is written on lldb-server side, then also lldb-server will have to wait for the inferior to stop in order to encapsulate all the traces in packets and send them

Re: [lldb-dev] FW: LLDB: Unwinding based on Assembly Instruction Profiling

Hi Jason Thanks a lot for the detailed information. I am sorry to post my queries a bit late. Here are few things that I want to ask. When eh_frame has epilogue description as well, the Assembly profiler doesn't need to augment it. In this case, is eh_frame augmented unwind plan used as Non Call

[lldb-dev] LLDB: Unwinding based on Assembly Instruction Profiling

Hi As far as I know, if the unwinding based on Assembly Instruction Profiling fails in LLDB then either EH frame unwinding or some other mechanism comes into picture to unwind properly. Am I right? In this case, should LLDB change the unwinder plan from Assembly Instruction Profiling to EH Frame

[lldb-dev] Layout of FXSAVE struct for x86 Architectures in LLDB

Hi all I was looking into the file "source/Plugins/Process/Utility/RegisterContext_x86.h" and I noticed one thing in FXSAVE structure. The 'ftag' is defined as a 16 bit field. However, on referring to Architecture Software Developer Manual for x86 architectures, one can see that the memory layout

Re: [lldb-dev] Offset Calculations for Registers on Linux x86_64

context's data. > Typically we should see: > > > > > > GPR > >rax offset 0 > >rbx offset 8 > > > > FPR > >mm0 offset 128 > > mm1 offset 160 > > ... > > EXC > >fpsr offset 256 > >

Re: [lldb-dev] Offset Calculations for Registers on Linux x86_64

.. > > > So the offsets should be based on the offset from the start of the one > large buffer that contains all register values. > > > On Aug 13, 2015, at 2:26 AM, Abhishek Aggarwal via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > > > Hello &g

[lldb-dev] Fwd: Offset Calculations for Registers on Linux x86_64

Hello I have a question regarding offset calculations of registers for x86_64 architecture. In file source/Plugins/Process/Utility/RegisterInfos_x86_64.h: The macro FPR_OFFSET(reg) calculates the offset of floating point register 'reg' with respect to 'UserArea' struct while GPR_OFFSET(reg) calcu