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