Convert the crashlog command to be implemented as a class. The Symbolicate
function is switched to a class, to implement get_long_help. The text for the
long help comes from the help output generated by OptionParser. That is, the
output of help crashlog is the same as crashlog --help.
Details
- Reviewers
jingham JDevlieghere - Commits
- rGcb5ea132d2ee: [lldb] Add long help to `crashlog`
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
The output of help crashlog is:
(lldb) help crashlog For more information run 'help crashlog' Expects 'raw' input (see 'help raw-input'.) Syntax: crashlog Usage: crashlog [options] <FILE> [FILE ...] Symbolicate one or more darwin crash log files to provide source file and line information, inlined stack frames back to the concrete functions, and disassemble the location of the crash for the first frame of the crashed thread. If this script is imported into the LLDB command interpreter, a "crashlog" command will be added to the interpreter for use at the LLDB command line. After a crash log has been parsed and symbolicated, a target will have been created that has all of the shared libraries loaded at the load addresses found in the crash log file. This allows you to explore the program as if it were stopped at the locations described in the crash log and functions can be disassembled and lookups can be performed using the addresses found in the crash log. Options: -h, --help show this help message and exit -v, --verbose display verbose debug info -g, --debug display verbose debug logging -a, --load-all load all executable images, not just the images found in the crashed stack frames --images show image list --debug-delay=NSEC pause for NSEC seconds for debugger -c, --crashed-only only symbolicate the crashed thread -d DISASSEMBLE_DEPTH, --disasm-depth=DISASSEMBLE_DEPTH set the depth in stack frames that should be disassembled (default is 1) -D, --disasm-all enabled disassembly of frames on all threads (not just the crashed thread) -B DISASSEMBLE_BEFORE, --disasm-before=DISASSEMBLE_BEFORE the number of instructions to disassemble before the frame PC -A DISASSEMBLE_AFTER, --disasm-after=DISASSEMBLE_AFTER the number of instructions to disassemble after the frame PC -C NLINES, --source-context=NLINES show NLINES source lines of source context (default = 4) --source-frames=NFRAMES show source for NFRAMES (default = 4) --source-all show source for all threads, not just the crashed thread -i, --interactive parse all crash logs and enter interactive mode
lldb/examples/python/crashlog.py | ||
---|---|---|
1236–1240 | 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". |
lldb/examples/python/crashlog.py | ||
---|---|---|
1236–1240 | 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. |
Oops, forgot to include the "why requesting changes..."
Can you see if also adding a "get_short_help" gets rid of that dopey:
For more information run 'help crashlog' Expects 'raw' input (see 'help raw-input'.)
line? It's getting added as the placeholder text in CommandObjectPythonObject & CommandObjectPythonFunction. It is not a very good place holder, but anyway having the short help is good for "apropos" listings and the like. And if those classes are doing the right thing, an actual short help should override the placeholder.
If adding the short help doesn't fix this, I'm fine with this change as is. We can go down the getting rid of that placeholder rabbit hole at some other time.
Add get_short_help, and add missing changes that should have been part of original diff.
Can you see if also adding a "get_short_help" gets rid of that dopey:
Good call, it worked.
lldb/examples/python/crashlog.py | ||
---|---|---|
1236–1240 | Yes I've come to learn to avoid "lldb.{debugger, target, process, thread, etc}" at all costs, which is how I was able to get past the strange error message.
It wasn't, which made things trickier to understand. Also note that the docs recommend this idiom used here in crashlog.py. Look for if __name__ == '__main__' in https://lldb.llvm.org/use/python-reference.html#create-a-new-lldb-command-using-a-python-function. |
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:
and this succeeds:
When using the first form, an error would happen when running the command. The error message is "no function to execute".