[lldb-dev] [Reproducers] SBReproducer RFC

Jonas Devlieghere via lldb-dev lldb-dev at lists.llvm.org
Fri Jan 4 13:19:02 PST 2019

Hi Everyone,

In September I sent out an RFC [1] about adding reproducers to LLDB. Over
past few months, I landed the reproducer framework, support for the GDB
protocol and a bunch of preparatory changes. There's still an open code
[2] for dealing with files, but that one is currently blocked by a change to
the VFS in LLVM [3].

The next big piece of work is supporting user commands (e.g. in the driver)
SB API calls. Originally I expected these two things to be separate, but
made a good case [4] that they're actually very similar.

I created a prototype of how I envision this to work. As usual, we can
differentiate between capture and replay.

## SB API Capture

When capturing a reproducer, every SB function/method is instrumented using
macro at function entry. The added code tracks the function identifier
(currently we use its name with __PRETTY_FUNCTION__) and its arguments.

It also tracks when a function crosses the boundary between internal and
external use. For example, when someone (be it the driver, the python
or the RPC server) call SBFoo, and in its implementation SBFoo calls SBBar,
don't need to record SBBar. When invoking SBFoo during replay, it will
call SBBar.

When a boundary is crossed, the function name and arguments are serialized
to a
file. This is trivial for basic types. For objects, we maintain a table that
maps pointer values to indices and serialize the index.

To keep our table consistent, we also need to track return for functions
return an object by value. We have a separate macro that wraps the returned

The index is sufficient because every object that is passed to a function
crossed the boundary and hence was recorded. During replay (see below) we
the index to an address again which ensures consistency.

## SB API Replay

To replay the SB function calls we need a way to invoke the corresponding
function from its serialized identifier. For every SB function, there's a
counterpart that deserializes its arguments and invokes the function. These
functions are added to the map and are called by the replay logic.

Replaying is just a matter looping over the function identifiers in the
serialized file, dispatching the right deserialization function, until no
data is available.

The deserialization function for constructors or functions that return by
contains additional logic for dealing with the aforementioned indices. The
resulting objects are added to a table (similar to the one described
that maps indices to pointers. Whenever an object is passed as an argument,
index is used to get the actual object from the table.

## Tool

Even when using macros, adding the necessary capturing and replay code is
tedious and scales poorly. For the prototype, we did this by hand, but we
propose a new clang-based tool to streamline the process.

For the capture code, the tool would validate that the macro matches the
function signature, suggesting a fixit if the macros are incorrect or
Compared to generating the macros altogether, it has the advantage that we
don't have "configured" files that are harder to debug (without faking line
numbers etc).

The deserialization code would be fully generated. As shown in the prototype
there are a few different cases, depending on whether we have to account for
objects or not.

## Prototype Code

I created a differential [5] on Phabricator with the prototype. It contains
necessary methods to re-run the gdb remote (reproducer) lit test.

## Feedback

Before moving forward I'd like to get the community's input. What do you
about this approach? Do you have concerns or can we be smarter somewhere?
feedback would be greatly appreciated!


[1] http://lists.llvm.org/pipermail/lldb-dev/2018-September/014184.html
[2] https://reviews.llvm.org/D54617
[3] https://reviews.llvm.org/D54277
[4] https://reviews.llvm.org/D55582
[5] https://reviews.llvm.org/D56322
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20190104/430b708b/attachment.html>

More information about the lldb-dev mailing list