This teaches lldb-test how to launch a process, set up an IRMemoryMap,
and issue memory allocations in the target process through the map. This
makes it possible to test IRMemoryMap in a targeted way.
The main motivation for testing IRMemoryMap is to uncover bugs. I've
noticed two so far. The first bug is that IRMemoryMap::Malloc performs
an adjustment on the pointer returned from Process::AllocateMemory (for
alignment purposes) which ultimately allows overlapping memory regions
to be created. The second bug is that after most of the address space on
the host side is exhausted, Malloc may return the same address multiple
times. These bugs (and hopefully more!) can be uncovered and tested for
with targeted lldb-test commands.
At an even higher level, the motivation for addressing bugs in
IRMemoryMap::Malloc is that they can lead to strange user-visible
failures (e.g, variables assume the wrong value during expression
evaluation, or the debugger crashes). See my third comment on this
[[ https://github.com/apple/swift-lldb/pull/652 | swift-lldb PR ]] for an example:
I hope lldb-test is the right place to test IRMemoryMap. Setting up a
gtest-style unit test proved too cumbersome (you need to recreate or
mock way too much debugger state), as did writing end-to-end tests (it's
hard to write a test that actually hits a buggy path).
With lldb-test, it's easy to read/generate the test input and parse the
test output. I'll attach a simple "fuzz" tester which generates failing test
cases with ease.
{F6288839}
Here's an example:
```
Command: malloc(size=1024, alignment=32)
Malloc: address = 0xca000
Command: malloc(size=64, alignment=16)
Malloc: address = 0xca400
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca440
Command: malloc(size=16, alignment=8)
Malloc: address = 0xca840
Command: malloc(size=2048, alignment=16)
Malloc: address = 0xcb000
Command: malloc(size=64, alignment=32)
Malloc: address = 0xca860
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca890
Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0)
```