[Lldb-commits] [lldb] [lldb] Use correct path for debugserver (PR #131609)

[Yuval Deutscher via lldb-commits]

https://github.com/yuvald-sweet-security created https://github.com/llvm/llvm-project/pull/131609

Hello,

This solves an issue that arises when running lldb-server through a symlink which is not named exactly `lldb-server`. For example, in many distros lldb-server is packaged as e.g. `/usr/lib/llvm-19/bin/lldb-server` which is then accessed through a symlink such as `/usr/bin/lldb-server-19`. In such a scenario, running `lldb-server-19 platform --server --listen '*:1338' --log-channels "lldb all"` works as intended, but running the absolute path of the symlink (`/usr/bin/lldb-server-19 platform --server --listen '*:1338' --log-channels "lldb all"`) fails with:

```
shlib dir -> `/usr/bin/`
Attempting to derive the path /bin relative to liblldb install path: /usr/bin
Derived the path as: /usr/bin
support exe dir -> `/usr/bin/`
GDBRemoteCommunicationServerPlatform::Handle_qLaunchGDBServer() debugserver launch failed: unable to locate lldb-server-19.1.7
```

It turns out that there is a cascade of bugs here:
* `GetShlibDir` attempts to locate the LLVM library directory by calling `GetModuleFileSpecForHostAddress` on the address of the function `ComputeSharedLibraryDirectory`, assuming that it is inside `liblldb.so`. However, in every packaging I've seen of lldb-server the function `ComputeSharedLibraryDirectory` is statically linked into the `lldb-server` binary and is not in `liblldb.so`.
* When run through a symlink, `GetModuleFileSpecForHostAddress` on an address that is in `lldb-server` returns the path of the symlink, not the path of the binary itself. So we get e.g. `/usr/bin/` and not `/usr/lib/llvm-19/bin/`.
  * `GetDebugserverPath` attempts to concat `"lldb-server"` to the directory we obtained, and thus fails when the symlink is not named exactly `lldb-server`.
* Ironically, the reason that this works in the first place is precisely because `GetModuleFileSpecForHostAddress` returns an incorrect path - when the server is run as `lldb-server-19 ...` it returns `"lldb-server-19"` which then causes `ComputePathRelativeToLibrary` to fail and then `ComputeSupportExeDirectory` falls back to just using `GetProgramFileSpec` instead (which is the only option that actually yields a correct path).

Given the above information, the most logical solution seems to be just ditching `GetSupportExeDir` in favor of `GetProgramFileSpec`, but I'm not sure what are the potential implications of this on different packaging of LLDB - perhaps there are situations where the `lldb` binary is not located in the same directory with `lldb-server`, and so we still want to use the follow-the-path-to-liblldb logic there? Please advise on how to proceed with this.

>From f47298e0f29a2a73d656ba5270557ca139688499 Mon Sep 17 00:00:00 2001
From: Yuval Deutscher <yuvald at sweet.security>
Date: Mon, 17 Mar 2025 14:37:26 +0200
Subject: [PATCH] [lldb] Use correct path for debugserver

---
 .../Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp       | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
index dad72a176b5fa..e754d01be3629 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
@@ -906,7 +906,7 @@ FileSpec GDBRemoteCommunication::GetDebugserverPath(Platform *platform) {
       FileSystem::Instance().Exists(debugserver_file_spec);
   if (!debugserver_exists) {
     // The debugserver binary is in the LLDB.framework/Resources directory.
-    debugserver_file_spec = HostInfo::GetSupportExeDir();
+    debugserver_file_spec.SetDirectory(HostInfo::GetProgramFileSpec().GetDirectory());
     if (debugserver_file_spec) {
       debugserver_file_spec.AppendPathComponent(DEBUGSERVER_BASENAME);
       debugserver_exists = FileSystem::Instance().Exists(debugserver_file_spec);