[lldb][test] Prevent TestqOffsets.py picking up host binaries #157432
Conversation
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
|
@llvm/pr-subscribers-lldb Author: David Spickett (DavidSpickett) ChangesDue 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 #155895 Full diff: https://github.com/llvm/llvm-project/pull/157432.diff 1 Files Affected:
diff --git a/lldb/test/API/functionalities/gdb_remote_client/TestqOffsets.py b/lldb/test/API/functionalities/gdb_remote_client/TestqOffsets.py
index a1adc20e864ba..e069f10b19e1e 100644
--- a/lldb/test/API/functionalities/gdb_remote_client/TestqOffsets.py
+++ b/lldb/test/API/functionalities/gdb_remote_client/TestqOffsets.py
@@ -10,6 +10,11 @@ class Responder(MockGDBServerResponder):
def qOffsets(self):
return "Text=470000;Data=470000"
+ def qfThreadInfo(self):
+ # Prevent LLDB defaulting to PID of 1 and looking up some other
+ # process when on an AArch64 host.
+ return "m-1"
+
def test(self):
self.server.responder = TestqOffsets.Responder()
target = self.createTarget("qOffsets.yaml")
|
There was a problem hiding this comment.
would runCmd("platform select remote-linux") have the same effect?
That would make the test more realistic, as that's how you would debug a non-local process. The problem right now is that lldb selects the host platform by default (you could argue that it shouldn't do that for "gdb-remote" connections, but that's what it is right now), and unless that platform rejects it (which happens when there's a host-binary architecture mismatch), it will bind the target to that platform. remote-linux (or maybe remote-gdb-server ?) is what would get selected then, so this will also make sure the behavior of the test is consistent between aarch64 and non-aarch64 runs.
|
I'll try it but I have a suspicion we have code that says "anything on localhost must be the host machine". |
That though, might skip dyld altogether. |
I hope we don't. The code I'm targetting is in TargetList::CreateTargetInternal, which gives preference to the selected platform. |
This does work. @tstellar can you confirm that this PR fixes the test for you? |
4 participants
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, select the remote-linux platform before creating the target. This means we won't attempt any host lookups.
Fixes #155895