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

[Pavel Labath via lldb-commits]

labath wrote:

> > Kind of yes, but the two issues are related. The issue with symlinks is that once you resolve them, there's no way to go back. I'm asking why (in the scenario you describe in that PR) does `GetModuleFileSpecForHostAddress` return "lldb-server-19" (instead of "/usr/bin/lldb-server-19" or "/usr/lib/llvm-19/bin/lldb-server")
> 
> So, regarding that issue - first of all, `GetModuleFileSpecForHostAddress` doesn't follow symlinks. I'm not sure if that's a bug or intended behavior but I don't see anything in `FileSystem::Resolve` that attempts to follow symlinks - it just makes a relative or `~`-path absolute.

I'm sorry, my bad. I saw the tilde resolution code and somehow assumed that canonicalization must follow. I think the lack of symlink resolution is intentional.

> 
> Now, what you said about resolving relative to cwd instead of relative to $PATH also happens there, but that's actually the reason the entire thing works in the first place - the fact that this resolves relative to cwd causes `ComputePathRelativeToLibrary` to fail

.. because of [this check](https://github.com/llvm/llvm-project/blob/9b1f905b483a2b42e4681bbef42b2641f8ccf5ad/lldb/source/Host/common/HostInfoBase.cpp#L237), presumably

> and then `ComputeSupportExeDirectory` falls back to using `GetProgramFileSpec`. So, this bug masks the first bug.

Got it. And I think I finally understand what those checks in ComputeSupportExeDirectory are doing.



> > Not exactly. I my use case, `lldb-server` would be a symlink to something like `/cas/dead/beef/baadf00d`. The symlink value is supposed to be an implementation detail of the CAS system. While the user could execute that directly, it wouldn't be totally surprising that it does not work.
> 
> Then maybe we should just execute the path given by `GetProgramFileSpec` but pass our argv[0] into execve's argv[0] (I don't know if the current process execution abstraction allows that)

I think that'd be fine, given that I know how to get GetProgramFileSpec to return the non-canonical path if that becomes necessary. And it matches what the code was doing originally. Process(Launch)Info has a [GS]etArg0 method, but it looks like ProcessLauncherPosixFork doesn't actually make use of it. It shouldn't be too hard to change that though. Would you like to try that? (If not, I can do it, probably next week)

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