[Lldb-commits] [lldb] [lldb][progress] Add discrete boolean flag to progress reports (PR #69516)
Greg Clayton via lldb-commits
lldb-commits at lists.llvm.org
Fri Dec 8 00:31:10 PST 2023
================
@@ -2225,7 +2225,8 @@ void ObjectFileMachO::ParseSymtab(Symtab &symtab) {
const char *file_name = file.GetFilename().AsCString("<Unknown>");
LLDB_SCOPED_TIMERF("ObjectFileMachO::ParseSymtab () module = %s", file_name);
LLDB_LOG(log, "Parsing symbol table for {0}", file_name);
- Progress progress(llvm::formatv("Parsing symbol table for {0}", file_name));
+ Progress progress(llvm::formatv("Parsing symbol table for {0}", file_name),
+ Progress::ProgressReportType::eAggregateProgressReport);
----------------
clayborg wrote:
I totally understand about timeframes and getting this in ASAP.
I am just trying to understand what the goal is here as what this change essentially does is groups all the progress notifications for all progress reports into the `is_aggregate == true` except for the SymbolLocationDefault's progress for downloading dSYM files. So essentially all progress notifications are considered spammy and something that won't get displayed? An enum means anytime someone adds a new progress, they need to make a category enum for it. I still think either a category string still makes the most sense. Then an IDE can watch for progress notifications, and if many come in from the same category, it can show a spinning progress with the category name "Parsing symbol tables" and any incoming progress updates could keep this progress UI alive. If a user opens up this top level "Parsing symbol tables" category, the individual progresses that are alive can be shown in detail. This allows an IDE to watch the progress notifications and if it gets too many too quickly from a specific category, it can group them all under the category name and not have to show specific individual entries that come and go too quickly.
The code from `SymbolFileDWARF::InitializeObject()` is what I am guessing can get really spammy for both the apple tables and DWARF5 tables. There is no work to be done when loading these tables, so I am guessing the progress is really quick for those and not that useful. We could remove these if they are some of the offending progress notifications that are causing issues.
Manual DWARF parsing and symbol table parsing, those do take some time, so they tend to be very useful as they really slow down debugger startup when you have large files and when users are sitting there watching a blank IDE window and no visible progress is made by the debugger, it can lead them to kill the debug session if there is no actual feedback.
https://github.com/llvm/llvm-project/pull/69516
More information about the lldb-commits
mailing list