[Lldb-commits] [PATCH] D33674: Implementation of Intel(R) Processor Trace support for Linux

Ravitheja Addepally via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Fri Jun 16 06:30:12 PDT 2017


ravitheja added inline comments.


================
Comment at: source/Plugins/Process/Linux/NativeProcessLinux.h:282
+  // same process user id.
+  llvm::DenseSet<lldb::tid_t> m_pt_traced_thread_group;
 };
----------------
labath wrote:
> ravitheja wrote:
> > labath wrote:
> > > I am confused about the purpose of this member variable. As far as I can tell, it will always contain *either* all of the threads in the process *or* none of them. Is there a situation where this is not the case?
> > Yes there can be situations like that, for e.g if a user starts tracing on an individual thread followed by tracing the whole process (meaning in two separate start trace calls) then this Set will contain the thread ids of all the threads except the one on which individual tracing was started. This can be extended further.
> Interesting... Is that actually useful for something? I find the semantic of "trace all threads in the process except those that happen to be traced already" a bit confusing. 
> 
> If you have a use for it in mind then fine, but otherwise, I'd like go for the simpler option of failing the request to trace the whole process if some individual threads are traced already. "you can either trace the whole process *OR* any number of individual threads" sounds much easier to understand. Otherwise, you'd have to think about corner cases like "What if the individual thread trace is stopped but the process trace request remains?" Do you then automatically start tracing the remaining thread based on the previous "whole process trace" request, and so on...
Yes thats what will happen. All threads spawned will be traced unless the tracing on the whole process is stopped.


https://reviews.llvm.org/D33674





More information about the lldb-commits mailing list