JDevlieghere added a comment. In https://reviews.llvm.org/D54617#1302366, @labath wrote:
> I am confused by differing scopes of various objects that are interacting > here. It seems you are implementing capture/replay as something that can be > flicked on/off at any point during a debug session (`Debugger` lifetime). > However, you are modifying global state (the filesystem singleton, at least), > which is shared by all debug sessions. If multiple debug sessions try to > enable capture/replay (or even access the filesystem concurrently, as none of > this is synchronized in any way), things will break horribly. This seems like > a bad starting point in implementing a feature, as I don't see any way to fix > incrementally in the future. Maybe I should've added a comment (I didn't want to litter the code with design goals) but the goal of the commands is not really to enable/disable the reproducer feature. I'm currently abusing the commands to do that, but the long term goal is that you can enable/disable part of the reproducer. For example, you could say only capture GDB packets or capture only files. It makes testing a lot easier if you can isolate a single source of information. Since there's currently only GDB packets I didn't split it up (yet). Also I piggy-backed off this to enable/disable the feature as a whole because I needed to go through the debugger. See my reply below on why and how that'll be fixed by the next patch :-) > Maybe you meant that by `Initialization of the FS needs to happen in the > driver.`? In any case, for me the initialization part is the interesting/hard > part of this problem. The details of how to collect the files are trivial > compared to that and possibly depend on the result of the decisions made > there. Yup, as per your suggestion in another review. I have an (unfinished) patch that splits off parsing of the command line arguments in the driver so we know the reproducer path before we initialize anything. That's pretty much the whole reason that we currently go through the debugger right now. Repository: rLLDB LLDB https://reviews.llvm.org/D54617 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
