[Lldb-commits] [PATCH] D131036: [lldb/crashlog] Add `-s|--skip-status` option to interactive mode
Jim Ingham via Phabricator via lldb-commits
lldb-commits at lists.llvm.org
Wed Aug 3 16:03:32 PDT 2022
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
More information about the lldb-commits
mailing list