Add AArch64 support to the premerge tests #155274
Conversation
|
Did we get quota from AWS for this? |
Yes, we did. Right now, I'm just trying to get a prototype working. |
|
✅ With the latest revision this PR passed the Python code formatter. |
|
There is still one failing test, but the implementation is complete (including sccache setup). |
Due to a fallback in GDBRemoteCommunicationClient.cpp, on Linux we will assume a PID of 1 if the remote does not respond in some way that tells us the real PID. So if PID 1 happened to be a process that the current user could read, we would try to debug that instead. On my current machine, PID 1 was sshd run by root so we would ignore it. If I changed the fallback to some process ID run by my user, the test would fail. To prevent this, return something to LLDB that tells it there is no remote PID, preventing the host lookup. Fixes llvm#155895
|
This is ready for review. I set the continue-on-error property for the aarch64 tests for now to allow for a stabilization period that doesn't impact users. |
|
Also, because I had to change the name of the tests to include the arch, we will need to update the rulset which requires the precommit tests to pass. |
| - depot-ubuntu-24.04-arm-16 | ||
| - llvm-premerge-linux-runners | ||
| runs-on: ${{ matrix.runs-on }} | ||
| container: |
There was a problem hiding this comment.
A comment here explaining we only explicitly spawn a container on AArch64?
There was a problem hiding this comment.
Is it because the GCP agents are containers themselves and we can't have nested containers?
No description provided.