[Lldb-commits] [PATCH] D117165: [lldb] Add long help to `crashlog`

[Jim Ingham via Phabricator via lldb-commits]

jingham requested changes to this revision.
jingham added inline comments.
This revision now requires changes to proceed.


================
Comment at: lldb/examples/python/crashlog.py:1236-1240
+def __lldb_init_module(debugger, internal_dict):
+    debugger.HandleCommand(
+        'command script add -c lldb.macosx.crashlog.Symbolicate crashlog')
+    debugger.HandleCommand(
         'command script add -f lldb.macosx.crashlog.save_crashlog save_crashlog')
----------------
kastiglione wrote:
> Note that I introduced `__lldb_init_module` here because there's some bug when registering a command class using `lldb.debugger`. In other words, this failed:
> 
> ```
> lldb.debugger.HandleCommand('command script add -c mod.Command cmd')
> ```
> 
> and this succeeds:
> 
> ```
> def __lldb_init_module(debugger, _):
>     debugger.HandleCommand('command script add -c mod.Command cmd')    
> ```
> 
> When using the first form, an error would happen when running the command. The error message is "no function to execute".
That makes sense.  All of the "lldb.{debugger, target, process, thread, etc}" variables are only set when entering the interactive script interpreter.  They don't get set when processing "command script import".  So lldb.debugger would have been None here.

In general, since pretty much no python we write in the lldb project is going to run in the interactive interpreter, you should never use those lldb.etc variables.

I actually think we could make the lldb.debugger work, since that really is a singleton for the command interpreter, but it seems much better form to pass debugger directly to whoever needs it, so for the sake of clarity they all get unset when we leave the interactive script interpreter.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117165