tree 9053ce3166a0edeb61549d1e73c55a45fb3b89db
parent adb671ea23af72c0fa1acd42103a5e9ca413d729
author Yuval Deutscher <yuvald@sweet.security> 1745315003 +0300
committer GitHub <noreply@github.com> 1745315003 +0200
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsFcBAABCAAQBQJoB2S7CRC1aQ7uu5UhlAAAJksQAG3H5jMWRuFQaI1xrIDTUDHJ
 MyF1mtb+w3vHM9qq4MppWWmm0OSPvHLExd5aCJ8Mn7Qri6rf80qsZRcafcs1A5pE
 +T9u0NsOVeMsivmbba00hNwK9zO9qfRflCSyHT7mNcn7rcyzuiV8yRUv+p6CkeAo
 oWYwBhptsEHFXBm+D0M+Qqz2gR003A8llAumtOgRPcxnpbrk2Ddr+adNV8Rxzu/P
 rE9xAkNNZprbJoF6KvwiN7O1og2WZaBx8OQaPY4Bw4H8Hx2+GF4wgUjdpmc3BJCx
 bM352KQ8w2xe0SbzqgBdlRUhKdzypT0U7QptqbKnVIMb/NxdlEsvnrMKWn5Jq5IO
 3WLzPu7OT2f0k8m6m9eFrqnuddPHE2yxXUW0eUd/DEomoSGESch+dgC9cZpdVNl3
 N7zoXadg4fnIEOxxrV4uhwCpg9XwGpJPwWF6tAWgEpt4NwGtLr6WIBluMJshGHCP
 RLanKSnhyIpz1WeS6CBcV3bCsQ3S1Zi5R/e6XdzpxRsAT7Z0GlUcKisiwZW5n6as
 XX7fcHbGwc7zpNWiAC7r006LmKsbxKCyhp3wXbnpICdKjCUJDsfJehWTaX58m8NQ
 3z5FQzA7GhdJ8iml4Jy4ZhmcxiM9khh23US4Il42KboncuSoyQC7rrCKXWqdsiek
 A64qdv0ED5GVF5L4mJa2
 =1uhN
 -----END PGP SIGNATURE-----
 

[lldb] Use correct path for debugserver (#131609)

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).