We have two different "process trace" implementations: per thread and per core. As a way to simplify the collector who uses both, I'm creating a base abstract class that is used by these implementations. This effectively simplify a good chunk of code.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
lldb/source/Plugins/Process/Linux/IntelPTCollector.h | ||
---|---|---|
73 | Could this be moved to be a part of the new IntelPTProcessTrace abstract class or is this also needed for handling thread trace? | |
lldb/source/Plugins/Process/Linux/IntelPTMultiCoreTrace.cpp | ||
36–38 | If this now returns IntelPTProcessTraceUP instead of an instance of itself, then we are basically forcing any uses of this class to be done using dynamic polymorphism (behind the indirection of a pointer to the super class). Should this instead return an instance of itself and then leave it up to the caller to decide if they want to use the object directly or behind a pointer? | |
119–125 | In TracesThread you check that the tid is a thread of m_process but in TraceStart you return success for all threads without checking if it's a part of the process. | |
lldb/source/Plugins/Process/Linux/IntelPTPerThreadProcessTrace.cpp | ||
58 | same comment here as above on the other subclasss | |
lldb/source/Plugins/Process/Linux/IntelPTProcessTrace.h | ||
20 |
lldb/source/Plugins/Process/Linux/IntelPTCollector.h | ||
---|---|---|
73 | i can't because you the reason you mention: thread trace | |
lldb/source/Plugins/Process/Linux/IntelPTMultiCoreTrace.cpp | ||
36–38 | good call | |
119–125 | ahh you are right | |
lldb/source/Plugins/Process/Linux/IntelPTPerThreadProcessTrace.cpp | ||
58 | +1 | |
lldb/source/Plugins/Process/Linux/IntelPTProcessTrace.h | ||
20 | +1 |
Could this be moved to be a part of the new IntelPTProcessTrace abstract class or is this also needed for handling thread trace?