vsk added a comment. I think this is moving in the right direction! However, the way ThreadTrace is specified still raises the same scalability concerns (see inline). The "instruction index" concept doesn't seem sufficient. Decoding needs to be done in two stages: a separate "trace index" concept would help with that. In the first stage, lldb identifies which subset of the trace it needs decoded by specifying start/stop trace indices. This should be fast, as counting the number of available trace bytes/"chunks" is O(1). Nothing needs to be decoded at this point. The second stage starts after a trace subset is decoded, and is where instruction indices are useful.
(I'll be OOO next week, but hope to pick up review on 6/21.) ================ Comment at: lldb/include/lldb/Target/ThreadTrace.h:68 + /// The number of available instructions in the trace. + virtual size_t GetInstructionCount() = 0; + ---------------- `GetInstructionCount` requires decoding the whole ThreadTrace (if not for PT, then for other tracing technologies). I don't think we can take the O(n) hit up front. ================ Comment at: lldb/include/lldb/Target/ThreadTrace.h:77 + /// The instruction type. + virtual lldb::TraceInstructionType GetInstructionType(size_t index) = 0; + ---------------- How does a a ThreadTrace client query what the valid range for indices is? ================ Comment at: lldb/include/lldb/lldb-enumerations.h:791 + /// The instruction is a conditional jump + eTraceInstructionCondJump, + /// The instruction writes custom data to the trace, e.g. Intel's PTWRITE. ---------------- Do we have an example of a generic trace analysis that needs to differentiate between conditional & unconditional branches? 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
