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
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
