[PATCH] D89283: [trace][intel-pt] Implement the basic decoding functionality
Vedant Kumar via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Oct 30 11:16:38 PDT 2020
vsk added inline comments.
================
Comment at: lldb/source/Plugins/Trace/intel-pt/DecodedThread.h:26
+public:
+ IntelPTError() = default;
+
----------------
Do we need a default constructor for this pure-virtual class?
================
Comment at: lldb/source/Plugins/Trace/intel-pt/DecodedThread.h:116
+ pt_insn m_pt_insn;
+ std::shared_ptr<IntelPTError> m_error;
+};
----------------
Still doesn't feel like this is aligning with the design of llvm::Error - they're supposed to be unique and lightweight. Specifically:
- Why is the error instance shareable? Do multiple threads need to handle the same error?
- For that matter, why is IntelPTInstruction copyable?
- How much are we gaining by storing the libipt_error_code vs. storing a `bool m_is_gap` field?
Imo it seems a bit too complicated to have three different ways to construct an IntelPTInstruction with an error. Would be nice to just have one?
================
Comment at: lldb/source/Plugins/Trace/intel-pt/DecodedThread.h:36
+
+ IntelPTInstruction(const pt_insn &pt_insn, int libipt_error_code = 0)
+ : m_pt_insn(pt_insn), m_libipt_error_code(libipt_error_code),
----------------
vsk wrote:
> Does this IntelPTInstruction constructor ever get called with a non-zero libipt error code?
Still wondering about this: why do we need to construct an IntelPTInstruction using a pt_insn as well as an error code?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D89283/new/
https://reviews.llvm.org/D89283
More information about the llvm-commits
mailing list