https://github.com/labath commented:
> 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). It's very hard to come up with a solution which makes everyone happy, which is why e.g. gcc/clang have a flag (`-no-canonical-prefixes`) to control this kind of behavior. I'm not thrilled by the idea of adding that to lldb, nor I think it would be practical for an interactive tool. 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)? 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
