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

[Pavel Labath via lldb-commits]

labath wrote:

> > > Ah, turns out there's a HostInfo::GetProgramFileSpec() function which solves both these issues.
> > 
> > 
> > I am aware of that function. The reason I did not suggest it is because `GetProgramFileSpec` (on linux) returns the canonical path (with all symlinks resolved). That's something I am generally trying to avoid because it can break some instalation types -- where the installation consists of a symlink farm and the expected installation layout is given by the symlink tree. (It can also fix some installations which expect exactly the opposite -- the debian use case in one of them).
> 
> I understand, but I think that for lldb-server this isn't much of an issue as it seems relatively stand-alone. I'd be more worried if this code attempted to execute a binary that isn't `lldb-server` from the LLVM binary directory; however, since this code is strictly used for lldb-server to re-execute itself with different arguments, I don't think relying on `GetProgramFileSpec` is an issue - and it is definitely better than using argv[0], which might as well be the canonical path, depending on how the user executed it.

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.

And the lldb-server binary is not completely standalone as it needs to execute the gdbserver binary (which on linux is actually still the same binary, but the code kind of doesn't know that), which is why you have #131609. In this scenario, there's no way to find the lldb-server binary (or anything else) because the CAS tree contains only a bunch of hex files.

That said, I'm slightly warming up towards using GetProgramFileSpec because I realized it is (mostly) possible (I'm not saying you have to do that) to implement it to return a non-canonical path by looking at auxiliary vector (AT_EXECFN). One tricky aspect of that is that if you execute the binary using a relative path (`./lldb-server`) then the auxiliary vector will contain a relative path, which means one would have to fetch it and make it absolute sufficiently early so that the CWD doesn't change.

> 
> > Whatever we do, I think it is better to resolve the symlink as late as possible as that gives us more options down the line. What I don't understand is why doesn't this work for your use case already -- `GetModuleFileSpecForHostAddress` calls `FileSystem::Resolve`, which should give you the canonical path for the library. Does that fail for some reason? It is it because the (relative) path returned by `GetModuleFileSpecForHostAddress` is resolved relative to CWD (but in reality we've executed it by finding the executable on the path)?
> 
> I'm assuming this is referring to the other issue, which I discuss in #131609? Because the issue in the current PR is not related to `GetModuleFileSpecForHostAddress` - `argv[0]` is piped directly into `spawn_process` without any canonicalization of paths.

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

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