Skip to content
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 tests only run on macos #81813

Open
ehuss opened this issue Feb 6, 2021 · 4 comments
Open

lldb tests only run on macos #81813

ehuss opened this issue Feb 6, 2021 · 4 comments
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@ehuss
Copy link
Contributor

ehuss commented Feb 6, 2021

The lldb tests only run on macos on CI. I think it might be worthwhile to run them on one CI builder for Linux, just to give a little more coverage. However, it's not really clear if anyone is actually using rust-lldb.

I discovered this because the debuginfo tests always fail on my local development system because I have lldb installed. This was a little frustrating, so I investigated and discovered that the pretty-std-collections.rs was not being tested on CI because it is ignored on macos, and it was broken a while ago.

It might be as easy as just adding apt install lldb to a builder. I don't think it is important to try to build it from source. Note that due to some oddity with how lldb apt package is installed, there is a missing symlink. Something like ln -s /usr/lib/llvm-10/bin/lldb-server /usr/bin/lldb-server-10.0.0 may be needed to get it to work.

@artemmukhin
Copy link
Contributor

A related and possibly helpful comment: #83891 (comment)

@pnkfelix pnkfelix added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. I-nominated labels Apr 28, 2021
@pnkfelix
Copy link
Member

I want to discuss this at the T-compiler meeting.

The on-going breakage of the debuginfo tests (and subsequent failure to catch such breakage in CI) is pretty worrisome, and frustrating as a contributor when all you want to do is run x.py test and let it go, without having to think too hard about "well which test suites are going to run that may be broken and that I have to skip myself by hand."

@apiraino
Copy link
Contributor

Issue has been discussed in T-compiler meeting on Zulip. This will probably need a follow up with T-infra.

Thus removing nomination:
@rustbot label -I-nominated

@ehuss ehuss added the A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) label Sep 17, 2021
@VladimirMakaev
Copy link
Contributor

I think something needs to be done here to make CI more robust. This isn't just about who uses "rust-lldb" (btw we do use the synth provider shipped with rust-lang in our tooling) this is also about changes in compiler potentially breaking LLDB. For instance while working on #124781 (comment) i've added and fixed a bunch of tests and made sure they work on LLDB 18.1.

I propose compiling LLDB from src/llvm-project and use this on CI (#124501 should help to set the binary up). We do compile Clang , do we? So compiling lldb should be straightforward. (We can do this on Linux only for instance at start). I can try dig into this direction or if there are pointers I can use please let me know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

6 participants