labath added a comment.
Hm... Are you sure that this will help with anything? IIUC, the serialization
of the VFS file map still happens in the context of the crashing process. This
requires walking a bunch of data structures with liberally-asserting code,
which will abort on any inconsistency it runs into. If *that* succeeds, I'd
expect that the copying of the files will succeed too.
I think it would be better if we moved the vfs map construction into the other
process too. Maybe via something like this:
- The first process opens a "log" file, which will contain the list of files to
be copied. For added safety the file should be opened append-only.
- As it works, it writes file names to this file.
- Upon a crash, the re-execed process reads this file, constructs the vfs map,
and copies all necessary files. It should be prepared to handle/ignore any
garbled entries, and the format of the file should make this easy. (Since the
log file must by definition contain enough information to recreate the vfs map,
it might be simpler to not write out the map, but just always recreate it in
memory when replaying.)
================
Comment at: lldb/tools/driver/Driver.cpp:857
+ str->append(" --reproducer-finalize ");
+ str->append(reproducer_path);
+ llvm::sys::AddSignalHandler(reproducer_handler,
----------------
I guess this won't work if there are spaces anywhere in the path..
================
Comment at: lldb/tools/driver/Options.td:235
HelpText<"Tells the debugger to replay a reproducer from <filename>.">;
+def reproducer_finalize: Separate<["--", "-"], "reproducer-finalize">,
+ MetaVarName<"<filename>">,
----------------
Should this be a hidden argument?
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D89600/new/
https://reviews.llvm.org/D89600
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
