bruno added a comment.
>> It seems conceptually a little strange to have the working directory be part >> of a serialized "FS", as it's fundamentally a property of a process and only >> transiently a property of the VFS. I tend to agree with @sammccall, it's odd that something that's usually transient to be considered an intrinsic part of the described filesystem. However, I also understand that the current way things are modeled in LLVM might not help with the big picture here. I'd like to know if you tried other approaches and why they failed. Would it be reasonable to instead have a property that list something resembling "preferred search paths" for the VFS in question? Seems more natural that the VFS could have the notion of where to look at things first (which can also be a list) instead of encoding a property that is usually transient. > From the reproducer's perspective I would argue that it is a property of the > VFS. More often than not, the working directory won't exist during replay. > That needs to be modeled somewhere, and VFS is the obvious candidate. What happens when besides a `current-working-directory` in the YAML, the user also passes `-working-directory` to clang? What's the expected semantics? On the LLDB side, could the reproducer be passing something like clang does with `-working-directory` for the purpose of having extra ways to find things? I'd imagine such mechanism to prepend some path to relative searches, which would yield a virtual absolute path to lookup at the VFS? Repository: rLLDB LLDB CHANGES SINCE LAST ACTION https://reviews.llvm.org/D65677/new/ https://reviews.llvm.org/D65677 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
