Hello All,
In the context of IntelĀ® Processor Trace support in LLDB I
asked, a while ago, about the syntax of remote packets.
Directions were mixed:
1. Taking GDBSERVER/GDB packets (available from 7.10)
2. Going to a brand new packets for
Do we need the server to know about the user ids we handed out to the
SB API client? AFAIK, you cannot have multiple traces of the same
thread running concurrently, so a thread-id should uniquely identify a
trace. The user id can then stay a client thing for abstracting the
concrete implementation
Hello,
Ok for the thread id we may use this QThreadSuffixSupported
extension but gdb packets also *don't have userid support *since gdb does
not have the concept of user id for trace instances. Also gdb uses seperate
packets for trace configuration and starting the trace.
On Tue, Apr 12,
I think we should reuse packets from the gdb protocol whereever it
makes sense. So, if they fit your needs (and a quick glance seems to
confirm that), then I think you should use them.
On 11 April 2016 at 15:28, Ravitheja Addepally wrote:
> Hello,
>Regarding the
We also need to think about all other types of tracing. It might make more
sense to keep these calls on SBProcess and have the calls simply be:
lldb::SBTrace lldb::SBProcess::StartTrace(SBTraceOptions _options,
lldb::SBError );
And you would need to specify which threads in the SBTraceOptions
I second Greg's suggestions, and I have some thoughts of my own:
- with the proposed API, it is not possible to get a trace for newly
created threads - the process needs to be stopped first, so you can
enable trace collection. There certainly are cases where this could be
problematic, e.g. if you
> On Mar 31, 2016, at 5:10 AM, Ravitheja Addepally via lldb-dev
> wrote:
>
> Hello all,
> I am currently working on enabling Intel (R) Processor Trace
> collection for lldb. I have done some previous discussions in this mailing
> list on this topic but
Hello all,
I am currently working on enabling Intel (R) Processor Trace
collection for lldb. I have done some previous discussions in this mailing
list on this topic but just to summarize , the path we chose was to
implement raw trace collection in lldb and the trace will be decoded