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
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
