================
@@ -3111,17 +3115,20 @@ void request_stackTrace(const llvm::json::Object
&request) {
// This will always return an invalid thread when
// libBacktraceRecording.dylib is not loaded or if there is no extended
// backtrace.
- lldb::SBThread queue_backtrace_thread =
- thread.GetExtendedBacktraceThread("libdispatch");
+ lldb::SBThread queue_backtrace_thread;
+ if (g_dap.enable_display_extended_backtrace)
+ queue_backtrace_thread =
thread.GetExtendedBacktraceThread("libdispatch");
if (queue_backtrace_thread.IsValid()) {
// One extra frame as a label to mark the enqueued thread.
totalFrames += queue_backtrace_thread.GetNumFrames() + 1;
}
// This will always return an invalid thread when there is no exception in
// the current thread.
- lldb::SBThread exception_backtrace_thread =
- thread.GetCurrentExceptionBacktrace();
+ lldb::SBThread exception_backtrace_thread;
+ if (g_dap.enable_display_extended_backtrace)
+ exception_backtrace_thread = thread.GetCurrentExceptionBacktrace();
----------------
jeffreytan81 wrote:
I don't have time to work on this. My goal is to quickly fix the performance
regression and unblock the business.
Frankly, the original PR should have been reverted initially, as it introduced
the regression.
The reasonable engineering process should involve landing this PR to disable
the performance regression. Then, the author of the original PR can fix it in
the desired way.
https://github.com/llvm/llvm-project/pull/104874
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
