alvinhochun created this revision.
Herald added a subscriber: mstorsjo.
Herald added a project: All.
alvinhochun requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.
LLDB tries to follow `EXCEPTION_RECORD::ExceptionRecord` to follow the
nested exception chain. In practice this code just causes Access
Violation whenever there is a nested exception. Since there does not
appear to be any code in LLDB that is actually using the nested
exceptions, this change just disables the crashing code and adds a
comment to clarify the reason.
Fixes https://github.com/mstorsjo/llvm-mingw/issues/292
Repository:
rG LLVM Github Monorepo
https://reviews.llvm.org/D128201
Files:
lldb/source/Plugins/Process/Windows/Common/ExceptionRecord.h
Index: lldb/source/Plugins/Process/Windows/Common/ExceptionRecord.h
===================================================================
--- lldb/source/Plugins/Process/Windows/Common/ExceptionRecord.h
+++ lldb/source/Plugins/Process/Windows/Common/ExceptionRecord.h
@@ -27,9 +27,19 @@
ExceptionRecord(const EXCEPTION_RECORD &record, lldb::tid_t thread_id) {
m_code = record.ExceptionCode;
m_continuable = (record.ExceptionFlags == 0);
+ // This marks some old code which tried to parse the nested exception. In
+ // practice, this code just causes Access Violation. I suspect
+ // `ExceptionRecord` here actually points to the address space of the
+ // debuggee process. However, I did not manage to find any official or
+ // unofficial reference that clarifies this point. If anyone would like to
+ // reimplement this, please also keep in mind to check how this behaves
when
+ // debugging a WOW64 process. I suspect you may have to use the explicit
+ // `EXCEPTION_RECORD32` and `EXCEPTION_RECORD64` structs.
+#if 0
if (record.ExceptionRecord)
m_next_exception.reset(
new ExceptionRecord(*record.ExceptionRecord, thread_id));
+#endif
m_exception_addr = reinterpret_cast<lldb::addr_t>(record.ExceptionAddress);
m_thread_id = thread_id;
m_arguments.assign(record.ExceptionInformation,
@@ -39,17 +49,18 @@
// MINIDUMP_EXCEPTIONs are almost identical to EXCEPTION_RECORDs.
ExceptionRecord(const MINIDUMP_EXCEPTION &record, lldb::tid_t thread_id)
: m_code(record.ExceptionCode), m_continuable(record.ExceptionFlags ==
0),
- m_next_exception(nullptr),
m_exception_addr(static_cast<lldb::addr_t>(record.ExceptionAddress)),
m_thread_id(thread_id),
m_arguments(record.ExceptionInformation,
record.ExceptionInformation + record.NumberParameters) {
+#if 0
// Set up link to nested exception.
if (record.ExceptionRecord) {
m_next_exception.reset(new ExceptionRecord(
*reinterpret_cast<const MINIDUMP_EXCEPTION
*>(record.ExceptionRecord),
thread_id));
}
+#endif
}
virtual ~ExceptionRecord() {}
@@ -57,9 +68,11 @@
DWORD
GetExceptionCode() const { return m_code; }
bool IsContinuable() const { return m_continuable; }
+#if 0
const ExceptionRecord *GetNextException() const {
return m_next_exception.get();
}
+#endif
lldb::addr_t GetExceptionAddress() const { return m_exception_addr; }
lldb::tid_t GetThreadID() const { return m_thread_id; }
@@ -69,7 +82,9 @@
private:
DWORD m_code;
bool m_continuable;
+#if 0
std::shared_ptr<ExceptionRecord> m_next_exception;
+#endif
lldb::addr_t m_exception_addr;
lldb::tid_t m_thread_id;
std::vector<ULONG_PTR> m_arguments;
Index: lldb/source/Plugins/Process/Windows/Common/ExceptionRecord.h
===================================================================
--- lldb/source/Plugins/Process/Windows/Common/ExceptionRecord.h
+++ lldb/source/Plugins/Process/Windows/Common/ExceptionRecord.h
@@ -27,9 +27,19 @@
ExceptionRecord(const EXCEPTION_RECORD &record, lldb::tid_t thread_id) {
m_code = record.ExceptionCode;
m_continuable = (record.ExceptionFlags == 0);
+ // This marks some old code which tried to parse the nested exception. In
+ // practice, this code just causes Access Violation. I suspect
+ // `ExceptionRecord` here actually points to the address space of the
+ // debuggee process. However, I did not manage to find any official or
+ // unofficial reference that clarifies this point. If anyone would like to
+ // reimplement this, please also keep in mind to check how this behaves when
+ // debugging a WOW64 process. I suspect you may have to use the explicit
+ // `EXCEPTION_RECORD32` and `EXCEPTION_RECORD64` structs.
+#if 0
if (record.ExceptionRecord)
m_next_exception.reset(
new ExceptionRecord(*record.ExceptionRecord, thread_id));
+#endif
m_exception_addr = reinterpret_cast<lldb::addr_t>(record.ExceptionAddress);
m_thread_id = thread_id;
m_arguments.assign(record.ExceptionInformation,
@@ -39,17 +49,18 @@
// MINIDUMP_EXCEPTIONs are almost identical to EXCEPTION_RECORDs.
ExceptionRecord(const MINIDUMP_EXCEPTION &record, lldb::tid_t thread_id)
: m_code(record.ExceptionCode), m_continuable(record.ExceptionFlags == 0),
- m_next_exception(nullptr),
m_exception_addr(static_cast<lldb::addr_t>(record.ExceptionAddress)),
m_thread_id(thread_id),
m_arguments(record.ExceptionInformation,
record.ExceptionInformation + record.NumberParameters) {
+#if 0
// Set up link to nested exception.
if (record.ExceptionRecord) {
m_next_exception.reset(new ExceptionRecord(
*reinterpret_cast<const MINIDUMP_EXCEPTION *>(record.ExceptionRecord),
thread_id));
}
+#endif
}
virtual ~ExceptionRecord() {}
@@ -57,9 +68,11 @@
DWORD
GetExceptionCode() const { return m_code; }
bool IsContinuable() const { return m_continuable; }
+#if 0
const ExceptionRecord *GetNextException() const {
return m_next_exception.get();
}
+#endif
lldb::addr_t GetExceptionAddress() const { return m_exception_addr; }
lldb::tid_t GetThreadID() const { return m_thread_id; }
@@ -69,7 +82,9 @@
private:
DWORD m_code;
bool m_continuable;
+#if 0
std::shared_ptr<ExceptionRecord> m_next_exception;
+#endif
lldb::addr_t m_exception_addr;
lldb::tid_t m_thread_id;
std::vector<ULONG_PTR> m_arguments;
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
