================
@@ -473,7 +473,8 @@ GetThreadContext_x86_64(RegisterContext *reg_ctx) {
lldb_private::minidump::MinidumpContext_x86_64_Flags::x86_64_Flag |
lldb_private::minidump::MinidumpContext_x86_64_Flags::Control |
lldb_private::minidump::MinidumpContext_x86_64_Flags::Segments |
- lldb_private::minidump::MinidumpContext_x86_64_Flags::Integer);
+ lldb_private::minidump::MinidumpContext_x86_64_Flags::Integer |
+ lldb_private::minidump::MinidumpContext_x86_64_Flags::LLDBSpecific);
----------------
Jlalond wrote:
I agree, the concern is extending the registers and other consumers/producers
being unable to consume the new registers. @clayborg and I talked about this
and the concern was if MSFT added new fields to the register context. However
looking at the [minidump
docs](https://learn.microsoft.com/en-us/windows/win32/api/minidumpapiset/ns-minidumpapiset-minidump_thread)
Thread Context is actually just an RVA. So we should be able to get away with
this.
@labath does Google or Brakepad include fs/gs_base and if they do can you point
me to some docs so we follow suite?
https://github.com/llvm/llvm-project/pull/106767
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
