[lldb] Show progress events in the command line driver

[JDevlieghere]

Summary

This patch adds support for showing progress events when using lldb on the command line. It spawns a separate thread that listens for progress events and prints them to the debugger's output stream.

It's nothing fancy (yet), for now it just prints the progress message. If we know the total number of items being processed, we prefix the message with something like [1/100], similar to ninja's output. It doesn't use any fancy terminal manipulation: it uses a simple carriage return (\r) to bring the cursor to the front of the line. If we support ANSI escape codes, we use a vt100 escape code to clear the current line when a progress event is complete. Otherwise we just overwrite it with as many spaces as the current terminal is wide.

Here's a recording of what this looks like in practice: https://asciinema.org/a/HBMDelpb9XDKccXZ09mgfuJ8R

[JDevlieghere]

Remove unrelated formatting changes

[mib]

Awesome! I could see this getting improved in the future by stacking each progress event in the output with their completion amount and popping the ones that are completed.

lldb/source/Core/Debugger.cpp

1727

1727

typo

1822

Why ?

[JDevlieghere]

• Fix typo
• Reduce stack size

lldb/source/Core/Debugger.cpp

1822

I copied this from StartIOHandlerThread, but you're absolutely right, we don't need that big of stack to handle events.

[JDevlieghere]

• Reduce flickering by not printing the last status message when the the progress is complete
• Add ... as suggested by Adrian offline
• Make ANSI (vt100) escape codes a requirement in order to show progress to simplify the code

[labath]

I like the feature, but why does it need to have a thread of it's own? Could this be done from inside the regular event handler thread? The event handler thread also prints to stdout, and it seems like a bad idea to have two threads trying to do the same...

[JDevlieghere]

• Move progress event handling in the regular event handler thread

[JDevlieghere]

• Unstage lldb/include/lldb/Interpreter/CommandInterpreter.h.

[aprantl]

This is pretty (and) awesome.

lldb/source/Core/Debugger.cpp

1659

side note: this function could benefit from some early exits.

1748

I guess Colors also implies it supports \r? Sure.
Can you comment what this escape sequence does?

[aprantl]

lldb/source/Core/Debugger.cpp

1743

And withColors also implies that it's an interactive TTY?

[JDevlieghere]

lldb/source/Core/Debugger.cpp

1743

Yup

1748

The comment on line 1760 explains that this clears the current line. I can move it down to make it more obvious.

[JDevlieghere]

• Make sure the output is both interactive and supports colors
• Add more comments

lldb/source/Core/Debugger.cpp

1743

Actually, I thought it did based on the docs, but looking at the implementation it's tracked by two different properties.

[clayborg]

lldb/source/Core/CoreProperties.td

137 ↗

(On Diff #413159)

Might be nice to clarify that this is for the CLI only?

Also, if this _is_ for the CLI only, the setting should probably be put into the "interpreter" settings as "interpreter.show-progress".

lldb/source/Core/Debugger.cpp

1742–1743

Move this to the top of the function so we don't do any work extracting anything from the event if it is disabled? Or is this code trying to limit the updates of a progress that reports many status updates for the same progress?

1749

If not interactive should we just dump the start and end progress events on a separate line?

1754

Do we want some sort of format string here that the user could modify as a setting? The idea would be there might be extra settings that the user could set like:

(lldb) setting set interpreter.progress-clear-line-format "${ansi....}"

and it could default to the above string. Not required, just thinking out loud here as I am reading the patch

1764–1765

If we did a format string for each message we could have something like:

"{${progress.is_start}...}{${progress.is_update}...}{${progress.is_end}...}"

where the "progress.is_start" variable would be true for the first progress event, "progress.is_update" would be true for any updates, and "progress.is_end" would be true if the progress is completed. This would allow people to customize how progress events get handled and printed. If someone just wants a start and end progress, then they can fill in the "..." after the "progress.is_start" and "progress.is_end". If they don't want updates, they can leave out the "{${progress.is_update}...}" section. It also would allow ansi colors to be used since we already support these. And this would allow non interactive sessions to still show progress if they want to (right now if it isn't interactive, it doesn't get shown).

[JDevlieghere]

Thanks for the review Greg!

lldb/source/Core/CoreProperties.td

137 ↗

(On Diff #413159)

I've updated the description to make it clear that this hinges of the debugger output being an interactive color enabled terminal.

lldb/source/Core/Debugger.cpp

1742–1743

Kind of. m_current_event_id ensures that we only deal with one event at the same time. If we moved this check before the m_current_event_id bookkeeping, someone could disable progress before the current progress event completes resulting in m_current_event_id never getting cleared.

For example:

event 1 begin -> m_current_event_id = 1
progress disabled 
event 1 end -> ignored
progress enabled
event 2 begin -> ignored because m_current_event_id == 1
and now every subsequent event is ignored because m_current_event_id will never get updated

1749

I (personally) think that will quickly generate too much output.

1754

Part of that is covered in https://reviews.llvm.org/D121062.

I didn't make the vt100 escape codes configurable. They're the same as what editline uses (which aren't configurable either) and to me are just implementation details.

1764–1765

I intentionally kept things simple for now, but this is definitely something we could make more sophisticated/configurable in the future.

[clayborg]

This is fine as a starting point, my only question is if the setting should be "interpreter.show-progress"

[jingham]

In D120972#3368008, @clayborg wrote:

This is fine as a starting point, my only question is if the setting should be "interpreter.show-progress"

Whether you see this output is really dependent on how the debugger's I/O is set up, which seems more like a feature of the Debugger than of the CommandInterpreter. This seems more like the stop display than like whether we prompt on quit or echo commands.

[JDevlieghere]

In D120972#3368055, @jingham wrote:

In D120972#3368008, @clayborg wrote:

This is fine as a starting point, my only question is if the setting should be "interpreter.show-progress"

Whether you see this output is really dependent on how the debugger's I/O is set up, which seems more like a feature of the Debugger than of the CommandInterpreter. This seems more like the stop display than like whether we prompt on quit or echo commands.

Exactly, there's nothing that ties this to the interpreter, so I think it makes sense to keep it where it is. I also tried to make that more explicit by referencing the debugger's output in the help message.

[clayborg]

In D120972#3368244, @JDevlieghere wrote:

In D120972#3368055, @jingham wrote:

In D120972#3368008, @clayborg wrote:

This is fine as a starting point, my only question is if the setting should be "interpreter.show-progress"

Whether you see this output is really dependent on how the debugger's I/O is set up, which seems more like a feature of the Debugger than of the CommandInterpreter. This seems more like the stop display than like whether we prompt on quit or echo commands.

Exactly, there's nothing that ties this to the interpreter, so I think it makes sense to keep it where it is. I also tried to make that more explicit by referencing the debugger's output in the help message.

ok. Thanks for the info

[thakis]

This breaks building on Windows where GetMessage is defined to GetMessageW: http://45.33.8.238/win/54664/step_4.txt

Please fix (just rename to something else), or revert for now if it takes a while to fix.

[JDevlieghere]

In D120972#3369002, @thakis wrote:

This breaks building on Windows where GetMessage is defined to GetMessageW: http://45.33.8.238/win/54664/step_4.txt

Please fix (just rename to something else), or revert for now if it takes a while to fix.

This was fixed by 43374bee0e0641be417f22fc73c46a914de5ea71

[labath]

lldb/source/Core/Debugger.cpp

1608

Why is this conditional on someone else listening for this event? We don't e.g. suppress the "Thread #N" blurb if someone is listening for eBroadcastBitThreadSelected

1608

(listening for this event at a specific point in time)

[JDevlieghere]

lldb/source/Core/Debugger.cpp

1608

My reasoning was that I didn't want us to handle events if someone else already is. What would be the canonical way to do this? Are you suggestion that we check it in the loop/callback?

[labath]

lldb/source/Core/Debugger.cpp

1608

I think the canonical way is to not do that. :) Events (except eStateChanged events) can go to multiple listeners and each one can handle them in his own way.

And there already is a setting controlling whether to print them, so anyone not interested can turn them off that way.

[clayborg]

I liked that part of the patch where it wouldn't report events through the debugger if someone is already handling them. lldb-vscode handles these events already, but we also set the debugger's out and error file handle to /dev/null

[jingham]

In D120972#3370529, @clayborg wrote:

I liked that part of the patch where it wouldn't report events through the debugger if someone is already handling them. lldb-vscode handles these events already, but we also set the debugger's out and error file handle to /dev/null

This seems a little like the stop notification, where we don't emit that info when running under Xcode (or I presume vscode). In the case of the stop notification, we're gating that on the Debugger::GetAsyncOutput stream being set or not. In this case we're switching on whether the result of Debugger::GetOutputFile is interactive. In both cases, this seems more like something the client should turn on and off explicitly, on for the Driver, off for Xcode & VSCode? Doing it based on whether the terminal is interactive or has an async output channel seems a little indirect.

[clayborg]

In D120972#3370688, @jingham wrote:

In D120972#3370529, @clayborg wrote:

I liked that part of the patch where it wouldn't report events through the debugger if someone is already handling them. lldb-vscode handles these events already, but we also set the debugger's out and error file handle to /dev/null

This seems a little like the stop notification, where we don't emit that info when running under Xcode (or I presume vscode). In the case of the stop notification, we're gating that on the Debugger::GetAsyncOutput stream being set or not. In this case we're switching on whether the result of Debugger::GetOutputFile is interactive. In both cases, this seems more like something the client should turn on and off explicitly, on for the Driver, off for Xcode & VSCode? Doing it based on whether the terminal is interactive or has an async output channel seems a little indirect.

This is only in the built in event loop, which lldb-vscode and Xcode do not use, they run their own event loops. So the only thing we are left with is the command line driver which uses this event loop.

[jingham]

In D120972#3370814, @clayborg wrote:

In D120972#3370688, @jingham wrote:

In D120972#3370529, @clayborg wrote:

I liked that part of the patch where it wouldn't report events through the debugger if someone is already handling them. lldb-vscode handles these events already, but we also set the debugger's out and error file handle to /dev/null

This seems a little like the stop notification, where we don't emit that info when running under Xcode (or I presume vscode). In the case of the stop notification, we're gating that on the Debugger::GetAsyncOutput stream being set or not. In this case we're switching on whether the result of Debugger::GetOutputFile is interactive. In both cases, this seems more like something the client should turn on and off explicitly, on for the Driver, off for Xcode & VSCode? Doing it based on whether the terminal is interactive or has an async output channel seems a little indirect.

This is only in the built in event loop, which lldb-vscode and Xcode do not use, they run their own event loops. So the only thing we are left with is the command line driver which uses this event loop.

It's a little lower than just the event loop, since this gets done in Process::HandleProcessStateChangedEvent. That gets called in a small handful of places including Process::WaitForProcessToStop, which gets called from a bunch of other places.

[jingham]

But using the standard event loop and "I want to handle async notifications by hand" seem like they should be separable choices.

[labath]

In D120972#3370850, @jingham wrote:

But using the standard event loop and "I want to handle async notifications by hand" seem like they should be separable choices.

Is the show-progress setting not enough of separation?

[jingham]

That's certainly good enough for users.

If you were the developer of another client, I think you'd want to keep people from inadvertently turning this back on. But that's probably a minor concern. And there isn't an equivalent good way to turn off the stop description from being printed if we ever make our way to HandleProgressEvent.

Jim

[JDevlieghere]

To summarize: I will remove the check because this doesn't matter for VSCode/Xcode because they don't use the default event loop and for those clients who might care about this, they should use the setting.

[labath]

Thanks.

lldb/include/lldb/API/SBCommandInterpreterRunOptions.h

public:
   bool GetPrintErrors() const;
 
   void SetPrintErrors(bool);
 
   bool GetAddToHistory() const;
 
   void SetAddToHistory(bool);
 
+  bool GetShowProgress() const;
+
+  void SetShowProgress(bool);
+
   bool GetAutoHandleEvents() const;
 
   void SetAutoHandleEvents(bool);
 
   bool GetSpawnThread() const;
 
   void SetSpawnThread(bool);
 

lldb/include/lldb/Core/Debugger.h

protected:
   bool HasIOHandlerThread();
 
   bool StartIOHandlerThread();
 
   void StopIOHandlerThread();
 
   void JoinIOHandlerThread();
 
+  bool StartProgressHandlerThread();
+
+  void StopProgressHandlerThread();
+
   lldb::thread_result_t IOHandlerThread();
 
   lldb::thread_result_t DefaultEventHandler();
 
+  lldb::thread_result_t ProgressHandlerThread();
+
   void HandleBreakpointEvent(const lldb::EventSP &event_sp);
 
   void HandleProcessEvent(const lldb::EventSP &event_sp);
 
   void HandleThreadEvent(const lldb::EventSP &event_sp);
 
   // Ensures two threads don't attempt to flush process output in parallel.
   std::mutex m_output_flush_mutex;
protected:
   llvm::StringMap<std::weak_ptr<llvm::raw_ostream>> m_log_streams;
   std::shared_ptr<llvm::raw_ostream> m_log_callback_stream_sp;
   ConstString m_instance_name;
   static LoadPluginCallbackType g_load_plugin_callback;
   typedef std::vector<llvm::sys::DynamicLibrary> LoadedPluginsList;
   LoadedPluginsList m_loaded_plugins;
   HostThread m_event_handler_thread;
   HostThread m_io_handler_thread;
+  HostThread m_progress_handler_thread;
   Broadcaster m_sync_broadcaster; ///< Private debugger synchronization.
   Broadcaster m_broadcaster;      ///< Public Debugger event broadcaster.
   lldb::ListenerSP m_forward_listener_sp;
   llvm::once_flag m_clear_once;
   lldb::TargetSP m_dummy_target_sp;
 
   // Events for m_sync_broadcaster
   enum {

lldb/include/lldb/Interpreter/CommandInterpreter.h

public:
   }
 
   bool GetAddToHistory() const { return DefaultToYes(m_add_to_history); }
 
   void SetAddToHistory(bool add_to_history) {
     m_add_to_history = add_to_history ? eLazyBoolYes : eLazyBoolNo;
   }
 
-  bool GetAutoHandleEvents() const {
-    return DefaultToYes(m_auto_handle_events);
+  bool GetShowProgress() const { return DefaultToYes(m_show_progress); }
+
+  void SetShowProgress(bool show_progress) {
+    m_show_progress = show_progress ? eLazyBoolYes : eLazyBoolNo;
   }
 
+  bool GetAutoHandleEvents() const { return DefaultToNo(m_auto_handle_events); }
+
   void SetAutoHandleEvents(bool auto_handle_events) {
     m_auto_handle_events = auto_handle_events ? eLazyBoolYes : eLazyBoolNo;
   }
 
   bool GetSpawnThread() const { return DefaultToNo(m_spawn_thread); }
 
   void SetSpawnThread(bool spawn_thread) {
     m_spawn_thread = spawn_thread ? eLazyBoolYes : eLazyBoolNo;
   }
 
   LazyBool m_stop_on_continue = eLazyBoolCalculate;
   LazyBool m_stop_on_error = eLazyBoolCalculate;
   LazyBool m_stop_on_crash = eLazyBoolCalculate;
   LazyBool m_echo_commands = eLazyBoolCalculate;
   LazyBool m_echo_comment_commands = eLazyBoolCalculate;
   LazyBool m_print_results = eLazyBoolCalculate;
   LazyBool m_print_errors = eLazyBoolCalculate;
   LazyBool m_add_to_history = eLazyBoolCalculate;
+  LazyBool m_show_progress;
   LazyBool m_auto_handle_events;
   LazyBool m_spawn_thread;
 
 private:
   static bool DefaultToYes(LazyBool flag) {
     switch (flag) {
     case eLazyBoolNo:
       return false;

lldb/source/API/SBCommandInterpreterRunOptions.cpp

 }
 
 void SBCommandInterpreterRunOptions::SetAddToHistory(bool add_to_history) {
   LLDB_INSTRUMENT_VA(this, add_to_history);
 
   m_opaque_up->SetAddToHistory(add_to_history);
 }
 
+bool SBCommandInterpreterRunOptions::GetShowProgress() const {
+  LLDB_INSTRUMENT_VA(this);
+
+  return m_opaque_up->GetShowProgress();
+}
+
+void SBCommandInterpreterRunOptions::SetShowProgress(bool spawn_thread) {
+  LLDB_INSTRUMENT_VA(this, spawn_thread);
+
+  m_opaque_up->SetShowProgress(spawn_thread);
+}
+
 bool SBCommandInterpreterRunOptions::GetAutoHandleEvents() const {
   LLDB_INSTRUMENT_VA(this);
 
   return m_opaque_up->GetAutoHandleEvents();
 }
 
 void SBCommandInterpreterRunOptions::SetAutoHandleEvents(
     bool auto_handle_events) {

lldb/source/Core/Debugger.cpp

lldb::thread_result_t Debugger::DefaultEventHandler() {
   listener_sp->StartListeningForEventSpec(m_broadcaster_manager_sp,
                                           thread_event_spec);
   listener_sp->StartListeningForEvents(
       m_command_interpreter_up.get(),
       CommandInterpreter::eBroadcastBitQuitCommandReceived |
           CommandInterpreter::eBroadcastBitAsynchronousOutputData |
           CommandInterpreter::eBroadcastBitAsynchronousErrorData);
 
   // Let the thread that spawned us know that we have started up and that we
   // are now listening to all required events so no events get missed
   m_sync_broadcaster.BroadcastEvent(eBroadcastBitEventThreadIsListening);
 
   bool done = false;
   while (!done) {
     EventSP event_sp;
     if (listener_sp->GetEvent(event_sp, llvm::None)) {
       if (event_sp) {
if (listener_sp->GetEvent(event_sp, llvm::None)) {
                 if (output_sp) {
                   output_sp->PutCString(data);
                   output_sp->Flush();
                 }
               }
             }
           }
         }
 
         if (m_forward_listener_sp)
           m_forward_listener_sp->AddEvent(event_sp);
       }
     }
   }
   return {};
 }
 

 }
 
 lldb::thread_result_t Debugger::IOHandlerThread() {
   RunIOHandlers();
   StopEventHandlerThread();
   return {};
 }
 
+lldb::thread_result_t Debugger::ProgressHandlerThread() {
+  // Only report progress for real terminals.
+  if (!GetOutputFile().GetIsRealTerminal())
+    return {};
+
+  // Only report progress if nobody else is listening for it.
+  if (GetBroadcaster().EventTypeHasListeners(Debugger::eBroadcastBitProgress))
+    return {};
+
+  ListenerSP listener_sp = Listener::MakeListener("lldb.progress.listener");
+  listener_sp->StartListeningForEvents(&m_broadcaster,
+                                       Debugger::eBroadcastBitProgress);
+
+  // Only handle one kind of event at the same time. Ignore events that come in
+  // in while the current event hasn't completed
+  llvm::Optional<uint64_t> CurrentEventID;
+
+  // Assume that the if the terminal supports colors (ANSI escape codes) it
+  // also supports vt100 escape codes.
+  const bool use_vt100_escapes = GetOutputFile().GetIsTerminalWithColors();
+
+  while (true) {
+    lldb::EventSP event_sp;
+    if (listener_sp->GetEvent(event_sp, llvm::None)) {
+      if (!event_sp)
+        continue;
+      if (auto *data = Debugger::ProgressEventData::GetEventDataFromEvent(
+              event_sp.get())) {
+
+        uint64_t id = data->GetID();
+        if (CurrentEventID) {
+          if (id != *CurrentEventID)
+            continue;
+        } else {
+          CurrentEventID = id;
+        }
+
+        std::string message = data->GetMessage();
+        if (data->GetTotal() != UINT64_MAX) {
+          GetOutputFile().Printf("[%llu/%llu] %s\r", data->GetCompleted(),
+                                 data->GetTotal(), message.c_str());
+        } else {
+          GetOutputFile().Printf("%s\r", message.c_str());
+        }
+
+        if (data->GetCompleted()) {
+          CurrentEventID.reset();
+          // Clear the current line. Use an escape character if supported,
+          // otherwise overwrite the line with a sequence of spaces.
+          if (use_vt100_escapes) {
+            GetOutputFile().Printf("\33[2K\r");
+          } else {
+            std::string clear(GetTerminalWidth(), ' ');
+            GetOutputFile().Printf("%s\r", clear.c_str());
+          }
+        }
+      }
+    }
+  }
+  return {};
+}
+
 bool Debugger::HasIOHandlerThread() { return m_io_handler_thread.IsJoinable(); }
 
 bool Debugger::StartIOHandlerThread() {
   if (!m_io_handler_thread.IsJoinable()) {
     llvm::Expected<HostThread> io_handler_thread = ThreadLauncher::LaunchThread(
         "lldb.debugger.io-handler", [this] { return IOHandlerThread(); },
         8 * 1024 * 1024); // Use larger 8MB stack for this thread
     if (io_handler_thread) {

 void Debugger::JoinIOHandlerThread() {
   if (HasIOHandlerThread()) {
     thread_result_t result;
     m_io_handler_thread.Join(&result);
     m_io_handler_thread = LLDB_INVALID_HOST_THREAD;
   }
 }
 
+bool Debugger::StartProgressHandlerThread() {
+  if (!m_progress_handler_thread.IsJoinable()) {
+    llvm::Expected<HostThread> progress_handler_thread =
+        ThreadLauncher::LaunchThread("lldb.debugger.progress-handler", [this] {
+          return ProgressHandlerThread();
+        });
+    if (progress_handler_thread) {
+      m_progress_handler_thread = *progress_handler_thread;
+    } else {
+      LLDB_LOG(GetLog(LLDBLog::Host), "failed to launch host thread: {}",
+               llvm::toString(progress_handler_thread.takeError()));
+    }
+  }
+
+  return m_io_handler_thread.IsJoinable();
+}
+
+void Debugger::StopProgressHandlerThread() {
+  if (m_progress_handler_thread.IsJoinable()) {
+    m_progress_handler_thread.Join(nullptr);
+  }
+}
+
 Target &Debugger::GetSelectedOrDummyTarget(bool prefer_dummy) {
   if (!prefer_dummy) {
     if (TargetSP target = m_target_list.GetSelectedTarget())
       return *target;
   }
   return GetDummyTarget();
 }
 

lldb/source/Interpreter/CommandInterpreter.cpp

m_command_io_handler_sp = std::make_shared<IOHandlerEditline>(
         *this, // IOHandlerDelegate
         GetDebugger().GetInputRecorder());
   }
   return m_command_io_handler_sp;
 }
 
 CommandInterpreterRunResult CommandInterpreter::RunCommandInterpreter(
     CommandInterpreterRunOptions &options) {
+  if (options.GetShowProgress())
+    m_debugger.StartProgressHandlerThread();
+
   // Always re-create the command interpreter when we run it in case any file
   // handles have changed.
   bool force_create = true;
   m_debugger.RunIOHandlerAsync(GetIOHandler(force_create, &options));
   m_result = CommandInterpreterRunResult();
 
   if (options.GetAutoHandleEvents())
     m_debugger.StartEventHandlerThread();

lldb/source/Symbol/LocateSymbolFile.cpp

 //===-- LocateSymbolFile.cpp ----------------------------------------------===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 
 #include "lldb/Symbol/LocateSymbolFile.h"
 
 #include "lldb/Core/ModuleList.h"
 #include "lldb/Core/ModuleSpec.h"
+#include "lldb/Core/Progress.h"
 #include "lldb/Host/FileSystem.h"
 #include "lldb/Symbol/ObjectFile.h"
 #include "lldb/Utility/ArchSpec.h"
 #include "lldb/Utility/DataBuffer.h"
 #include "lldb/Utility/DataExtractor.h"
 #include "lldb/Utility/LLDBLog.h"
 #include "lldb/Utility/Log.h"
 #include "lldb/Utility/Reproducer.h"

 FileSpec
 Symbols::LocateExecutableSymbolFile(const ModuleSpec &module_spec,
                                     const FileSpecList &default_search_paths) {
   FileSpec symbol_file_spec = module_spec.GetSymbolFileSpec();
   if (symbol_file_spec.IsAbsolute() &&
       FileSystem::Instance().Exists(symbol_file_spec))
     return symbol_file_spec;
 
+  Progress progress(llvm::formatv(
+      "Locating external symbol file for {0}",
+      module_spec.GetFileSpec().GetFilename().AsCString("<Unknown>")));
+
   FileSpecList debug_file_search_paths = default_search_paths;
 
   // Add module directory.
   FileSpec module_file_spec = module_spec.GetFileSpec();
   // We keep the unresolved pathname if it fails.
   FileSystem::Instance().ResolveSymbolicLink(module_file_spec,
                                              module_file_spec);
 

lldb/tools/driver/Driver.cpp

if ((commands_stream.GetData() != nullptr) &&
     }
 
     // Set the debugger into Sync mode when running the command file. Otherwise
     // command files that run the target won't run in a sensible way.
     bool old_async = m_debugger.GetAsync();
     m_debugger.SetAsync(false);
 
     SBCommandInterpreterRunOptions options;
+    options.SetShowProgress(true);
     options.SetAutoHandleEvents(true);
     options.SetSpawnThread(false);
     options.SetStopOnError(true);
     options.SetStopOnCrash(m_option_data.m_batch);
     options.SetEchoCommands(!m_option_data.m_source_quietly);
 
     SBCommandInterpreterRunResult results =
         m_debugger.RunCommandInterpreter(options);