Because the data formatter for the compiler internals was registering itself as
swift, it was hiding the default data formatters for swift code.
rdar://125114526
Without `--expand`, only the summary is shown, no child nodes. Adding `--expand` allows
for printing the child nodes, to be printed too.
Follow up to https://github.com/apple/swift/pull/40568
The `__future__` we relied on is now, where the 3 specific things are
all included [since Python 3.0](https://docs.python.org/3/library/__future__.html):
* absolute_import
* print_function
* unicode_literals
* division
These import statements are no-ops and are no longer necessary.
The routine already supports dumping the assembly to file if we are at a
breakpoint using the current frame. This adds a -n option so one can without
running just dump the assembly to a file of a specific function in a binary.
* More Python3 lint fixes
Some of the issues addressed include:
* Don't use `l` as a variable name (confusable with `1` or `I`)
* `print` statement does not exist in Py3, use `print` function instead
* Implicit tuple deconstruction in function args is no longer supported,
use explicit splat `*` at the call site instead
* `xrange` does not exist in Py3, use `range` instead
* Better name per review feedback
Just something I cooked up really quickly b/c I needed it. If you want to use
this, lldb-with-tools will auto-import it, so I suggest that you use that.
The initial version of the debugger testing transform instruments
assignments in a way that allows the debugger to sanity-check its
expression evaluator.
Given an assignment expression of the form:
```
a = b
```
The transform rewrites the relevant bits of the AST to look like this:
```
{ () -> () in
a = b
checkExpect("a", stringForPrintObject(a))
}()
```
The purpose of the rewrite is to make it easier to exercise the
debugger's expression evaluator in new contexts. This can be automated
by having the debugger set a breakpoint on checkExpect, running `expr
$Varname`, and comparing the result to the expected value generated by
the runtime.
While the initial version of this testing transform only supports
instrumenting assignments, it should be simple to teach it to do more
interesting rewrites.
There's a driver script available in SWIFT_BIN_DIR/lldb-check-expect to
simplfiy the process of launching and testing instrumented programs.
rdar://36032055
Sometimes it is really useful to be able to dump the disassembly from lldb into
a file so that one can work with the disassembly in an editor. The disassemble
command in lldb does not provide such facility today. So this lldb function in
the lldb toolbox provides such a facility.
This works by dumping the disassembly of the current assembly frame into a
temporary file and then running:
blockifyasm < tmpfile | viewcfg
without having to leave lldb.
I also fixed a small bug in the lldb-with-tools.in script where the input was
passed onto lldb as:
lldb -O '...' -- $@
The -- should not have been there since sometimes one wants to /not/ use a --
argument form to lldb.
This is a simple tool that starts lldb, but before it runs your commands, uses
the -O command to load lldbToolBox.py. This provide sthe llvm data formatters as
well as potential future lldb extensions that we write for swift itself.
A better name for this utility would be much appreciated, but I think for now
the name "lldb-with-tools" is at least self explanatory.
