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 lldb/lldbserve
Well the point of the user ids was to support multiple trace technologies
for the same thread, so in that case the thread id is not sufficient for
uniquely identifying the trace. Now I guess the server would need to be
aware of the user-id if multiple trace technologies are active on the same
threa
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, 20
LLDB already has the QThreadSuffixSupported extension, which adds the
";thread:" suffix to a bunch of packets. We could say that if the
client requests this extension, we will support it on these packets as
well. Otherwise we fall back to the "Hg" thingy.
I haven't looked at how hard it would be t
One of the downsides of using the gdb protocol is that these packets are
stateful meaning the thread id option is not there and the word btrace
stands for branch trace which basically suggests execution tracing.
On Mon, Apr 11, 2016 at 4:50 PM, Pavel Labath wrote:
> I think we should reuse packe
ation Collaborative Project
-Original Message-
From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Pavel
Labath via lldb-dev
Sent: Monday, April 11, 2016 9:51 AM
To: Ravitheja Addepally
Cc: LLDB
Subject: Re: [lldb-dev] Review of API and remote packets
I think we should
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 packet definitions for tra
Hello,
Regarding the packet definitions for tracing, how about reusing the
existing btrace packets ?
https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#qXfer%20btrace%20read
On Fri, Apr 1, 2016 at 7:13 PM, Greg Clayton wrote:
> We also need to think about all other type
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 &trace_options,
lldb::SBError &error);
And you would need to specify which threads in the SBT
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 just to summarize , the pa
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
o
13 matches
Mail list logo
