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
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
