llvmbot wrote:
<!--LLVM PR SUMMARY COMMENT--> @llvm/pr-subscribers-lldb Author: Yuval Deutscher (yuvald-sweet-security) <details> <summary>Changes</summary> 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. --- Full diff: https://github.com/llvm/llvm-project/pull/131609.diff 1 Files Affected: - (modified) lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp (+1-1) ``````````diff 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); `````````` </details> https://github.com/llvm/llvm-project/pull/131609 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
