You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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`.
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).
0 commit comments