[Lldb-commits] [PATCH] D53532: [FileSystem] Extend file system and have it use the VFS.
Pavel Labath via Phabricator via lldb-commits
lldb-commits at lists.llvm.org
Tue Oct 30 12:19:01 PDT 2018
labath added a comment.
In https://reviews.llvm.org/D53532#1280734, @JDevlieghere wrote:
> In https://reviews.llvm.org/D53532#1280018, @labath wrote:
> > In https://reviews.llvm.org/D53532#1279022, @JDevlieghere wrote:
> > > Address Pavel's feedback:
> > >
> > > - Change to `Initialize` method which can only be called once.
> > I suppose this is slightly better, but what I meant was to have a `static` (like all other functions with the same name) `Initialize` function, which has to be called before the first call to `Instance()`. During normal startup, this could be called from `SystemInitializer`, but I am not sure how would that work for record/replay (that's why I was asking how you planned to initialize those). It would require to setup the record/replay machinery very early on, which may be tricky. But on the other hand, you probably want to initialize these as early as possible anyway.
> > Do you think something like that would be possible?
> Alright, I see what you mean. You know more about the architecture, but it looks like we initialize the system before even reading the command line arguments in the driver. I have to read the reproducer before I can set the appropriate file system, so I'm not sure if this is possible.
Yes, right now it certainly seems to be the case that we parse cmdline late in the game. However, it's not clear to me whether that has to be the case.
I can't say I have thought this through to the end, but it seems to me that setting up the repro engine should be one of the first (if not THE first) SB calls from the driver. Right now the parsing happens too late (e.g. we already have an SBDebugger instance created at that point). I am not sure you could safely initialize record/replay at that point, even if you got FileSystem switching working.
Architecturally, the cleanest solution to me seems to be doing the command line parsing (even if it's just the repro-related args) before SBDebugger::Initialize, and then have special versions of the `Initialize` function like `Initialize(args_for_record)` and `Initialize(args_for_replay)`. The interesting repro-related stuff would then happen in these functions, which can then call the `Initialize` functions of relevant components (like `FileSystem`) and pass appropriate arguments.
However, I can't say how would that fit into your intended design or any code you already have implemented.
More information about the lldb-commits