[Lldb-commits] [lldb] [lldb] Use correct path for lldb-server executable (PR #131519)

[Yuval Deutscher via lldb-commits]

yuvald-sweet-security wrote:

> I'm wondering if the right fix isn't to call `FileSystem::ResolveExecutableLocation` on `argv[0]`. That should should give us more-or-less the same algorithm that the shell used when starting lldb-server.

Perhaps, but note that technically argv[0] doesn't really have to be related to the name of the executable at all - the user can pretty much pass whatever value they want as argv[0] when calling execve (although I agree that it would be a very peculiar workflow for someone to run lldb-server with an argv[0] that isn't the name of the binary).

On another note, I am currently debugging few other regressions introduced in LLDB 20 that relate to the way the platform mode server executes another server internally. For example, while this patch makes `lldb-server` work as intended if e.g. installed to `/usr/local/bin/lldb-server`, if I install it as `/usr/local/bin/not-lldb-server`, then it functions right when invoked as `not-lldb-server` but does *not* function right if invoked with an absolute path because LLDB does not correctly deduce the support exe directory, which is very curious behaviour indeed:

```
$ sudo ln -s /home/user/random/llvm-project/build/bin/lldb-server /usr/local/bin/not-lldb-server

$ not-lldb-server platform --server --listen '*:1338' --log-channels "lldb all"
Listen to [*]:1338
Listen to [*]:0
Connection established.
started monitoring child process.
lldb-platform launched '/home/user/random/llvm-project/build/bin/lldb-server platform --child-platform-fd 8 --gdbserver-port 37663 --log-channels lldb all', pid=49632
thread created
0x587b5409a160 Socket::Close (fd = 8)
pid = 49632
::waitpid(49632, &status, 0)...
Launching debugserver url='', fd=8...
shlib dir -> `(empty)`
support exe dir -> `/home/user/random/llvm-project/build/bin/`
started monitoring child process.
thread created
GDBRemoteCommunicationServerPlatform::LaunchGDBServer() debugserver launched successfully as pid 49672
pid = 49672
::waitpid(49672, &status, 0)...
0x00007FFE94504A88 Communication::Disconnect ()
0x587b5409d900 Socket::Close (fd = 8)
::waitpid(49672, &status, 0) => pid = 49672, status = 0x0
pid = 49672 thread exiting...
^C

$ /usr/local/bin/not-lldb-server platform --server --listen '*:1338' --log-channels "lldb all"                                                                                                                              Listen to [*]:1338
Listen to [*]:0
Connection established.
started monitoring child process.
lldb-platform launched '/home/user/random/llvm-project/build/bin/lldb-server platform --child-platform-fd 8 --gdbserver-port 40461 --log-channels lldb all', pid=49799
0x5d0837133160 Socket::Close (fd = 8)
thread created
pid = 49799
::waitpid(49799, &status, 0)...
Launching debugserver url='', fd=8...
shlib dir -> `/usr/local/bin/`
Attempting to derive the path /bin relative to liblldb install path: /usr/local/bin
Derived the path as: /usr/local/bin
support exe dir -> `/usr/local/bin/`
GDBRemoteCommunicationServerPlatform::LaunchGDBServer() debugserver launch failed: unable to locate lldb-server
0x00007FFE655B2738 Communication::Disconnect ()
0x5d0837136900 Socket::Close (fd = 8)
Launching debugserver url='', fd=8...
GDBRemoteCommunicationServerPlatform::LaunchGDBServer() debugserver launch failed: unable to locate lldb-server
0x00007FFE655B2738 Communication::Disconnect ()
0x5d083716e340 Socket::Close (fd = 8)
```

(This is an important workflow because that is precisely the way that lldb-server gets installed in distro packaging, e.g. `lldb-server-20` links to the `lldb-server` binary in the LLVM installation directory)

https://github.com/llvm/llvm-project/pull/131519