jingham added a comment. The code looks fine to me. This is a new capability, and I don't see how we can guess with certainty whether the clients want this output or not, so I think we should add it as an explicit option, as in the current patch.
================ Comment at: lldb/examples/python/crashlog.py:1198-1204 + option_parser.add_option( + '--skip-status', + '-s', + dest='skip_status', + action='store_true', + help='prevent the interactive crashlog to dump the process status and thread backtrace at launch', + default=False) ---------------- JDevlieghere wrote: > Is there another way to detect that we're running in this kind of > environment? For example, could we check if we're in an interactive lldb > session? I imagine you'd like to have the same behavior as the IDE case if > you imported the crashlog module in another Python file for example. One easy > way to determine this is to check if `lldb.debugger` exists, but I'm not sure > if that will cover the IDE case you're trying to solve. I don't think we should be in the business of trying to auto-detect what the caller's intentions are in this regard. For instance, I can easily imagine a python utility that wants to get the crashlog, show it to the user, and also do some logic on it, and having us dump it is really convenient. Plus the development experience here would be bad. Someone would try out the crashlog command in lldb and see the dump. Then they would run it in their program and not see it. Then I think they would take our names in vain... Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D131036/new/ https://reviews.llvm.org/D131036 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
