[PATCH] D101340: Allows for dsymutil crashes to generate reproduceable information

Jonas Devlieghere via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Feb 16 17:39:21 PST 2022


JDevlieghere added a comment.

I was thinking about it some more and a bunch of complexity here seems to come from the fact that some stuff happens within the CrashRecoveryContext (i.e. `dsymutilMain`). I believe we can avoid the majority of it by parsing the option, initializing the reproducer, and then running the remaining work in the `RunSafely` lamba.

I also think we should be able to avoid the `dyn_cast` and rely on polymorphism instead. For example we could have a virtual `generate(bool crashed)` method that is called after CRC.RunSafely. For `ReproducerGenerate` it would unconditionally generate the reproducer. For `ReproducerGenerateOnCrash` it would only do so if `crashed == true`.



================
Comment at: llvm/tools/dsymutil/Reproducer.cpp:108
+    Repro = std::make_unique<ReproducerGenerateForCrash>(EC);
+    LLVM_FALLTHROUGH;
+  case ReproducerMode::Generate:
----------------
feg208 wrote:
> JDevlieghere wrote:
> > Why is this a fallthrough? It seems like now, if we fail to create the `ReproducerGenerateForCrash` instance, we'll try creating a regular `ReproducerGenerate` and only then print the error message? I think we should just handle the EC immediately. 
> I don't think so. But maybe my read is incorrect? The unique_ptr would still get created and thus the nullptr check wouldn't pass and so the ec check below would still do its thing.
I would prefer to handle the error immediately and make every switch case self contained.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D101340/new/

https://reviews.llvm.org/D101340



More information about the llvm-commits mailing list