[Lldb-commits] [PATCH] D103588: [trace] Create a top-level instruction class
walter erquinigo via Phabricator via lldb-commits
lldb-commits at lists.llvm.org
Tue Jun 8 18:49:46 PDT 2021
wallace added a comment.
I've been thinking about what you said and I'm having second thoughts on my implementation. I'll share more context:
- I want to work in the short term on reverse debugging and reconstruction of stack traces, for that i'll need to know the instruction type of each instruction in the trace, which will be used as part of some heuristics to identify calls and returns between functions.
- A future application that we plan to work on is adding profiling information to the instructions
- Right now the intel-pt plugin is storing the decoded instructions in a vector, which works for small traces but wont' for gigantic traces. I imagine that I'll end up removing that vector and make the TraverseInstruction API decode instructions in place keeping one instruction in memory at a time within the intel pt plugin for a given traversal. For that I'll need accessors that can provide information of the current Instruction. As there could be two or more concurrent traversals happening at the same time (I'm trying to be generic here), it might make sense to create an abstract class TraceInstruction that can be extended by each plug-in and implement its getters.
I'm thinking about something like this
class TraceInstruction {
virtual lldb::addr_t GetLoadAddress() = 0;
virtual TraceInstructionType() GetInstructionType() = 0;
virtual uint64_t GetTimestamp() = 0;
... anything that can appear in the future
};
and have no members, leaving to each plug-in the decision of which of those methods to implement and how.
What do you think of this? I think this incorporates your feedback.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D103588/new/
https://reviews.llvm.org/D103588
More information about the lldb-commits
mailing list