[lldb] Show module name in progress update for downloading symbols (#85342) #8414
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ether the image is in the shared cache. (llvm#83341) The help for the `-r` option to `image list` says: -r[<width>] ( --ref-count=[<width>] ) Display the reference count if the module is still in the shared module cache. but that's not what it actually does. It unconditionally shows the use_count for all Module shared pointers, regardless of whether they are still in the shared module cache or whether they are just in the ModuleCollection and other entities are keeping them alive. That seems like a more useful behavior, but then it is also useful to know what's in the shared cache, so I changed this to: -r[<width>] ( --ref-count=[<width>] ) Display whether the module is still in the the shared module cache (Y/N), and its shared pointer use_count. So instead of just `{5}` you will see `{Y 5}` if it is in the shared cache and `{N 5}` if not. I didn't add tests for this because I'm not sure how much we want to fix shared cache behavior in the testsuite. (cherry picked from commit 9728170)
…lvm#85342) Currently, we always show the argument passed to dsymForUUID in the corresponding progress update. Most of the time this is a UUID, but it can also be an absolute path. The former is pretty uninformative and the latter needlessly noisy. This changes the progress update to print the UUID and the module name, if both are available. Otherwise, we print the UUID or the module name depending on which one is available. We now also unconditionally pass the module file spec and architecture to DownloadObjectAndSymbolFile, while previously this was conditional on the file existing on-disk. This should be harmless: - We already check that the file exists in DownloadObjectAndSymbolFile. - It doesn't make sense to check the filesystem for the architecutre. rdar://124643548 (cherry picked from commit b7dd601)
|
@swift-ci please test |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, we always show the argument passed to dsymForUUID in the
corresponding progress update. Most of the time this is a UUID, but it
can also be an absolute path. The former is pretty uninformative and the
latter needlessly noisy.
This changes the progress update to print the UUID and the module name,
if both are available. Otherwise, we print the UUID or the module name
depending on which one is available.
We now also unconditionally pass the module file spec and architecture
to DownloadObjectAndSymbolFile, while previously this was conditional on
the file existing on-disk. This should be harmless:
rdar://124643548
(cherry picked from commit b7dd601)