[lldb] DebugInfoD tests & fixes (but with dwp testing disabled) #98344
Conversation
This file contains 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
This reverts commit 7fc2fbb.
…Arch64/Arm buildbots
|
@JDevlieghere or @clayborg if one of you could please approve & land this, I believe this disables the tests that caused the previous diff to be reverted. |
JDevlieghere
approved these changes
Jul 10, 2024
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/59/builds/1331 Here is the relevant piece of the build log for the reference: |
keith
added a commit
to keith/llvm-project
that referenced
this pull request
Jul 10, 2024
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/18/builds/616 Here is the relevant piece of the build log for the reference: |
keith
added a commit
that referenced
this pull request
Jul 10, 2024
|
"fixed forward" with PR98351 if someone can approve & land that (it just disabled the baseline test for DWP stuff, as well: I missed it because the dwp tests run on all the machines I have access to :/ ) |
clayborg
pushed a commit
that referenced
this pull request
Jul 10, 2024
This should disable the failing test on the ubuntu build bots @JDevlieghere (I forgot to disable the 'baseline' test, as it tests the debugger's basic handling of DWP files, but again, the API infrastructure doesn't quite support DWP generation) #98344 (comment)
aaryanshukla
pushed a commit
to aaryanshukla/llvm-project
that referenced
this pull request
Jul 14, 2024
…#98344) This is all the tests and fixes I've had percolating since my first attempt at this in January. After 6 months of trying, I've given up on adding the ability to test DWP files in LLDB API tests. I've left both the tests (disabled) and the changes to Makefile.rules in place, in the hopes that someone who can configure the build bots will be able to enable the tests once a non-borked dwp tool is widely available. Other than disabling the DWP tests, this continues to be the same diff that I've tried to land and [not](llvm#90622) [revert](llvm#87676) [five](llvm#86812) [times](llvm#85693) [before](llvm#96802). There are a couple of fixes that the testing exposed, and I've abandoned the DWP tests because I want to get those fixes finally upstreamed, as without them DebugInfoD is less useful.
aaryanshukla
pushed a commit
to aaryanshukla/llvm-project
that referenced
this pull request
Jul 14, 2024
aaryanshukla
pushed a commit
to aaryanshukla/llvm-project
that referenced
this pull request
Jul 14, 2024
This should disable the failing test on the ubuntu build bots @JDevlieghere (I forgot to disable the 'baseline' test, as it tests the debugger's basic handling of DWP files, but again, the API infrastructure doesn't quite support DWP generation) llvm#98344 (comment)
walter-erquinigo
added a commit
that referenced
this pull request
Jul 16, 2024
This reverts commit 2fa1220. This reverts commit b9496a7. The patch #98344 causes a crash in LLDB when parsing some files like `numpy.libs/libgfortran-daac5196.so.5.0.0` on graviton (you can download it in https://drive.google.com/file/d/12ygLjJwWpzdYsrzBPp1JGiFHxcgM0-XY/view?usp=drive_link if you want to troubleshoot yourself). The assert that is hit is the following: ``` llvm-project/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp:2452: std::pair<unsigned int, std::map<long unsigned int, lldb_private::AddressClass> > ObjectFileELF::ParseSymbolTable(lldb_private::Symtab*, lldb::user_id_t, lldb_private::Section*): Assertion `strtab->GetObjectFile() == this' failed. [383588:383636:20240716,025305.572639:ERROR crashpad_client_linux.cc:780] Crashpad isn't enabled ``` This object file doesn't have apparently a strings table but LLDB still tries to process it due to the code that is being reverted.
|
@kevinfrei , I'm so sorry to tell you that I have reverted this patch. The revert commit is 27b2f4f and I left some notes there, which I also copy here: The patch #98344 causes a crash in LLDB when parsing some files like |
Reverted with a repro instead of some inscrutable "This didn't work on a build machine configured by someone 4 years ago who promptly forgot what they did and there's no documentation, but here's this log: good luck!" is glorious! I'll get on it- thanks 😃 |
|
@kevinfrei , I'm glad I can be of help to you! Let me know if you want me to try out your next iteration of this PR on my device. |
yuxuanchen1997
pushed a commit
that referenced
this pull request
Jul 25, 2024
Summary: This reverts commit 2fa1220. This reverts commit b9496a7. The patch #98344 causes a crash in LLDB when parsing some files like `numpy.libs/libgfortran-daac5196.so.5.0.0` on graviton (you can download it in https://drive.google.com/file/d/12ygLjJwWpzdYsrzBPp1JGiFHxcgM0-XY/view?usp=drive_link if you want to troubleshoot yourself). The assert that is hit is the following: ``` llvm-project/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp:2452: std::pair<unsigned int, std::map<long unsigned int, lldb_private::AddressClass> > ObjectFileELF::ParseSymbolTable(lldb_private::Symtab*, lldb::user_id_t, lldb_private::Section*): Assertion `strtab->GetObjectFile() == this' failed. [383588:383636:20240716,025305.572639:ERROR crashpad_client_linux.cc:780] Crashpad isn't enabled ``` This object file doesn't have apparently a strings table but LLDB still tries to process it due to the code that is being reverted. Test Plan: Reviewers: Subscribers: Tasks: Tags: Differential Revision: https://phabricator.intern.facebook.com/D60251733
JDevlieghere
pushed a commit
that referenced
this pull request
Aug 6, 2024
…ing with stripped binaries (#99362) @walter-erquinigo found the the [PR with testing and a fix for DebugInfoD](#98344) caused an issue when working with stripped binaries. The issue is that when you're working with split-dwarf, there are *3* possible files: The stripped binary the user is debugging, the "only-keep-debug" *or* unstripped binary, plus the `.dwp` file. The debuginfod plugin should provide the unstripped/OKD binary. However, if the debuginfod plugin fails, the default symbol locator plugin will just return the stripped binary, which doesn't help. So, to address that, the SymbolVendorELF code checks to see if the SymbolLocator's ExecutableObjectFile request returned the same file, and bails if that's the case. You can see the specific diff as the second commit in the PR. I'm investigating adding a test: I can't quite get a simple repro, and I'm unwilling to make any additional changes to Makefile.rules to this diff, for Pavlovian reasons.
banach-space
pushed a commit
to banach-space/llvm-project
that referenced
this pull request
Aug 7, 2024
…ing with stripped binaries (llvm#99362) @walter-erquinigo found the the [PR with testing and a fix for DebugInfoD](llvm#98344) caused an issue when working with stripped binaries. The issue is that when you're working with split-dwarf, there are *3* possible files: The stripped binary the user is debugging, the "only-keep-debug" *or* unstripped binary, plus the `.dwp` file. The debuginfod plugin should provide the unstripped/OKD binary. However, if the debuginfod plugin fails, the default symbol locator plugin will just return the stripped binary, which doesn't help. So, to address that, the SymbolVendorELF code checks to see if the SymbolLocator's ExecutableObjectFile request returned the same file, and bails if that's the case. You can see the specific diff as the second commit in the PR. I'm investigating adding a test: I can't quite get a simple repro, and I'm unwilling to make any additional changes to Makefile.rules to this diff, for Pavlovian reasons.
TIFitis
pushed a commit
that referenced
this pull request
Aug 8, 2024
…ing with stripped binaries (#99362) @walter-erquinigo found the the [PR with testing and a fix for DebugInfoD](#98344) caused an issue when working with stripped binaries. The issue is that when you're working with split-dwarf, there are *3* possible files: The stripped binary the user is debugging, the "only-keep-debug" *or* unstripped binary, plus the `.dwp` file. The debuginfod plugin should provide the unstripped/OKD binary. However, if the debuginfod plugin fails, the default symbol locator plugin will just return the stripped binary, which doesn't help. So, to address that, the SymbolVendorELF code checks to see if the SymbolLocator's ExecutableObjectFile request returned the same file, and bails if that's the case. You can see the specific diff as the second commit in the PR. I'm investigating adding a test: I can't quite get a simple repro, and I'm unwilling to make any additional changes to Makefile.rules to this diff, for Pavlovian reasons.
kstoimenov
pushed a commit
to kstoimenov/llvm-project
that referenced
this pull request
Aug 15, 2024
…ing with stripped binaries (llvm#99362) @walter-erquinigo found the the [PR with testing and a fix for DebugInfoD](llvm#98344) caused an issue when working with stripped binaries. The issue is that when you're working with split-dwarf, there are *3* possible files: The stripped binary the user is debugging, the "only-keep-debug" *or* unstripped binary, plus the `.dwp` file. The debuginfod plugin should provide the unstripped/OKD binary. However, if the debuginfod plugin fails, the default symbol locator plugin will just return the stripped binary, which doesn't help. So, to address that, the SymbolVendorELF code checks to see if the SymbolLocator's ExecutableObjectFile request returned the same file, and bails if that's the case. You can see the specific diff as the second commit in the PR. I'm investigating adding a test: I can't quite get a simple repro, and I'm unwilling to make any additional changes to Makefile.rules to this diff, for Pavlovian reasons.
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.
This is all the tests and fixes I've had percolating since my first attempt at this in January. After 6 months of trying, I've given up on adding the ability to test DWP files in LLDB API tests. I've left both the tests (disabled) and the changes to Makefile.rules in place, in the hopes that someone who can configure the build bots will be able to enable the tests once a non-borked dwp tool is widely available.
Other than disabling the DWP tests, this continues to be the same diff that I've tried to land and not revert five times before. There are a couple of fixes that the testing exposed, and I've abandoned the DWP tests because I want to get those fixes finally upstreamed, as without them DebugInfoD is less useful.