[PATCH] D54277: Extend VFS with function to get external path.

[Jonas Devlieghere via Phabricator via llvm-commits]

JDevlieghere added a comment.

In https://reviews.llvm.org/D54277#1296661, @sammccall wrote:

> In https://reviews.llvm.org/D54277#1296400, @JDevlieghere wrote:
>
> > In https://reviews.llvm.org/D54277#1296175, @sammccall wrote:
> >
> > > I don't understand the concept of an "external path". What is it in the general case, when would you want to pass a path through this function vs using it directly?
> > >
> > > From the patch description, it sounds like it may be specific to LLDB and/or RedirectingFileSystem. If so, maybe it shouldn't be on the interface?
> >
> >
> > It's true that this is only relevant for VFS implementations that are somehow backed by disk. I'm curious what you have in mind. How would it not be on the interface and still work transparently?
>
>
> I can't really answer these questions without knowing what an external path is or when you'd want to use it.
>  Could you describe it here or add some documentation to the patch?


I'll try here first and we can always improve the patch later.

Let's start from the beginning: I'm adding reproducer functionality to LLDB. Just like in clang, we need files to be available somewhere else form where they actually live on disk. This should also be transparent to the consumer. I want to use the VFS for this rather than hand-rolling my own implementation in LLDB. I did a whole bunch of refactoring to make most of LLDB's file system operations go through the VFS.

One notable difference between llvm/clang and LLDB is how the latter deals with files. In addition to using memory buffers, LLDB manipulates the majority of files through file pointers (`FILE*`) and file descriptors. It's also a lot less explicit in whether it's opening a file for reading or writing. By this I mean in llvm we have functions like `openMemoryBufferForWriting` or `openMemoryBufferForReading` while in LLDB we would just pass a different open flag. While I would love to change how LLDB manipulates files, I simply don't have the bandwidth to do that right now. So that brings me to my current problem: how do I access files from LLDB through the VFS.

I considered extending the VFS API with functions to provide access to file pointers and descriptors, but decided against it. The reason is that (AFAIK) there's no way to access memory through either of those on both windows and unix. I believe you can have a `FILE*`to memory but that doesn't work on Windows. File descriptors to memory don't make sense on either.

The alternative, proposed in this patch, is to have an API in the VFS to access the "underlying" file through its "external path". This is the path specified in YAML by `external-contents`. So when the VFS thinks that the file `foo` lives at `/root/foo` but it actually lives at `/root/whatever/reproducer/foo`, I want to be able to get that latter path and open it with (f)open.

Please let me know if this makes things more clear.


https://reviews.llvm.org/D54277