-
Notifications
You must be signed in to change notification settings - Fork 12k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[LLDB] DebugInfoD tests: attempt to fix Fuchsia build #96802
[LLDB] DebugInfoD tests: attempt to fix Fuchsia build #96802
Conversation
@petrhosek Is there a way you can help @kevinfrei validate this on Fuchsia |
Specifically, I'm adding tests that require dwp/llvm-dwp laying around somewhere, and it looks like Fuchsia doesn't put it in the 'normal' location, and I have no idea how to simply disable an LLDB test for Fuchsia, because it lies to the infra and says it's linux (which is probably the right lie to tell, but I can't find any mechanism to see that it's a flower-flavored variant of Linux...) Here's the build failure, where you can see it can't find the 'dwp' tool: https://luci-milo.appspot.com/ui/p/fuchsia/builders/toolchain.ci/clang-linux-x64/b8747217173107569041/test-results?sortby=&groupby= |
What do you mean by "normal" location? Our toolchain has The builder description is correct, it's a Linux distribution (Debian) but we don't install GNU toolchains, we're strict about using Clang/LLVM toolchain which is why there's no It looks like |
"normal" as defined by whoever wrote Makefile.rules originally and thought that was the correct place to file tools like ar and objcopy, I guess? So, on your build machine, do you know where the llvm-dwp file might be installed? Because honestly, I'd rather just use that thing instead of assuming the GNU dwp tool is around. |
It'd be right next to |
02c5d66
to
5414fd5
Compare
883ba67
to
8c304f9
Compare
This reverts commit 7fc2fbb.
…Arch64/Arm buildbots
8c304f9
to
2ee5bd2
Compare
@JDevlieghere could you stamp this so I can see if I've managed to make the tests work on the Fuchsia build (which I can't reproduce locally) |
Friendly ping @JDevlieghere |
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/59/builds/1213 Here is the relevant piece of the build log for the reference:
|
Reverts #96802 Attempt #5 fails. It's been 6 months. I despise Makefile.rules and have no ability to even *detect* these failures without _landing_ a diff. In the mean time, we have no testing for DWP files at all (and a regression that was introduced, that I fix with this diff) so I'm going to just remove some of the tests and try to land it again, but with less testing I guess.
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](#90622) [revert](#87676) [five](#86812) [times](#85693) [before](#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.
This is the same diff I've put up at many times before. I've been trying to add some brand new functionality to the LLDB test infrastucture (create split-dwarf files!), and we all know that no good deed goes unpunished. The last attempt was reverted because it didn't work on the Fuchsia build. There are no code differences between this and [the](llvm#90622) [previous](llvm#87676) [four](llvm#86812) [diffs](llvm#85693) landed & reverted (due to testing infra failures). The only change in this one is the way `dwp` is being identified in `Makefile.rules`. Thanks to @petrhosek for helping me figure out how the fuchsia builders are configured. I now prefer to use llvm-dwp and fall back to gnu's dwp if the former isn't found. Hopefully this will work everywhere it needs to.
…98101) Reverts llvm#96802 Attempt llvm#5 fails. It's been 6 months. I despise Makefile.rules and have no ability to even *detect* these failures without _landing_ a diff. In the mean time, we have no testing for DWP files at all (and a regression that was introduced, that I fix with this diff) so I'm going to just remove some of the tests and try to land it again, but with less testing I guess.
…#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.
This is the same diff I've put up at many times before. I've been trying to add some brand new functionality to the LLDB test infrastucture (create split-dwarf files!), and we all know that no good deed goes unpunished. The last attempt was reverted because it didn't work on the Fuchsia build.
There are no code differences between this and the previous four diffs landed & reverted (due to testing infra failures). The only change in this one is the way
dwp
is being identified inMakefile.rules
.Thanks to @petrhosek for helping me figure out how the fuchsia builders are configured. I now prefer to use llvm-dwp and fall back to gnu's dwp if the former isn't found. Hopefully this will work everywhere it needs to.