================
@@ -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:
> @clayborg I understand your point but how would a category string be
> different from filtering out the progress events based on the progress title
> string (or parts of it) ?
It would stop clients from having to add logic to try and look for common
substrings, but other than that not much different. It would allow progress
titles to vary quite a bit more, but they don't right now.
> I see how certain progress reports could be relevant to linux where we
> wouldn't want to surface it on macOS. The reason we came up with this
> approach is precisely because we prefer having LLDB tell its clients what
> progress should be displayed, rather than having the filtering logic be done
> in the client.
Not sure I follow? Are you saying if `is_aggregate == true` that we are letting
users know they should ignore these progress reports? And we are setting to
true for all progress reports except for Swift and a few other rarely used ones?
> May we could keep a list of blacklisted progress title / categories for every
> platform and either submit progress reports if they're not in that list or
> have an SBAPI to fetch the list of blacklisted progresses from the client ?
> What do you think about this ?
One ideas is if we have categories, we could have settings that could control
if the progress reports for a given category should be displayed. Those could
easily be set after initializing a debugger object.
> (also cc @JDevlieghere since he will probably have some opinions about this).
Sounds good
The entire idea of the progress dialogs is to provide insight for when the
debugger seems to be stalled, but it is actually doing work. If we have any
progress items that are not useful, we should remove them. But parsing symbol
tables, even on Mac, can sometimes take a few seconds on larger binaries, so I
find this useful when running LLDB from the command line. Indexing DWARF is a
huge time sync for really large projects which often can take many minutes to
complete and when I load them on the command line, seeing the progress in the
terminal is very useful.
So a few things that seem to stand out to me:
- Darwin will never see the `Manually indexing DWARF for <path>` progress
dialogs, and these are needed and should always be displayed.
- Darwin does see the `Parsing symbol table for <path> progress dialogs, but
many are fast and probably are part of the problem you want to fix?
- "Loading Apple DWARF index for <path>" has no real work being done here, just
initializing a memory buffer, seems like it should probably be removed to cut
down on the noise?
- "Loading DWARF5 index for <path>" is the same kind of thing for both Darwin
and linux (no real work to be done, the accelerator tables are "ready to use")
- "Locating external symbol file for <path>" seems useful if the download can
take a while
I don't see any other uses in the upstream LLDB sources.
But my main point is we make Progress dialogs for a reason and we should make
sure they are useful and that everyone wants them.
https://github.com/llvm/llvm-project/pull/69516
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
