[lldb-dev] [RFC] LLDB Reproducers
Leonard Mosescu via lldb-dev
lldb-dev at lists.llvm.org
Wed Sep 19 10:48:42 PDT 2018
Great, thanks. This means that the lldb-server issues are not in scope for
this feature, right?
On Wed, Sep 19, 2018 at 10:09 AM, Jonas Devlieghere <jdevlieghere at apple.com>
> On Sep 19, 2018, at 6:49 PM, Leonard Mosescu <mosescu at google.com> wrote:
> Sounds like a fantastic idea.
> How would this work when the behavior of the debugee process is
> All the communication between the debugger and the inferior goes through
> GDB remote protocol. Because we capture and replay this, we can reproduce
> without running the executable, which is particularly convenient when you
> originally debugging something on a different device for example.
> On Wed, Sep 19, 2018 at 6:50 AM, Jonas Devlieghere via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
>> Hi everyone,
>> We all know how hard it can be to reproduce an issue or crash in LLDB.
>> are a lot of moving parts and subtle differences can easily add up. We
>> want to
>> make this easier by generating reproducers in LLDB, similar to what clang
>> The core idea is as follows: during normal operation we capture whatever
>> information is needed to recreate the current state of the debugger. When
>> something goes wrong, this becomes available to the user. Someone else
>> then be able to reproduce the same issue with only this data, for example
>> on a
>> different machine.
>> It's important to note that we want to replay the debug session from the
>> reproducer, rather than just recreating the current state. This ensures
>> that we
>> have access to all the events leading up to the problem, which are
>> usually far
>> more important than the error state itself.
>> # High Level Design
>> Concretely we want to extend LLDB in two ways:
>> 1. We need to add infrastructure to _generate_ the data necessary for
>> 2. We need to add infrastructure to _use_ the data in the reproducer to
>> the debugging session.
>> Different parts of LLDB will have different definitions of what data they
>> to reproduce their path to the issue. For example, capturing the commands
>> executed by the user is very different from tracking the dSYM bundles on
>> Therefore, we propose to have each component deal with its needs in a
>> way. This has the advantage that the functionality can be developed and
>> ## Providers
>> We'll call a combination of (1) and (2) for a given component a
>> `Provider`. For
>> example, we'd have an provider for user commands and a provider for dSYM
>> A provider will know how to keep track of its information, how to
>> serialize it
>> as part of the reproducer as well as how to deserialize it again and use
>> it to
>> recreate the state of the debugger.
>> With one exception, the lifetime of the provider coincides with that of
>> `SBDebugger`, because that is the scope of what we consider here to be a
>> debug session. The exception would be the provider for the global module
>> because it is shared between multiple debuggers. Although it would be
>> conceptually straightforward to add a provider for the shared module
>> this significantly increases the complexity of the reproducer framework
>> of its implication on the lifetime and everything related to that.
>> For now we will ignore this problem which means we will not replay the
>> construction of the shared module cache but rather build it up during
>> replaying, as if the current debug session was the first and only one
>> using it.
>> The impact of doing so is significant, as no issue caused by the shared
>> cache will be reproducible, but does not limit reproducing any issue
>> to it.
>> ## Reproducer Framework
>> To coordinate between the data from different components, we'll need to
>> introduce a global reproducer infrastructure. We have a component
>> for reproducer generation (the `Generator`) and for using the reproducer
>> `Loader`). They are essentially two ways of looking at the same unit of
>> repayable work.
>> The Generator keeps track of its providers and whether or not we need to
>> generate a reproducer. When a problem occurs, LLDB will request the
>> to generate a reproducer. When LLDB finishes successfully, the Generator
>> up anything it might have created during the session. Additionally, the
>> Generator populates an index, which is part of the reproducer, and used
>> by the
>> Loader to discover what information is available.
>> When a reproducer is passed to LLDB, we want to use its data to replay the
>> debug session. This is coordinated by the Loader. Through the index
>> created by
>> the Generator, different components know what data (Providers) are
>> and how to use them.
>> It's important to note that in order to create a complete reproducer, we
>> require data from our dependencies (llvm, clang, swift) as well. This
>> that either (a) the infrastructure needs to be accessible from our
>> or (b) that an API is provided that allows us to query this. We plan to
>> this issue when it arises for the respective Generator.
>> # Components
>> We have identified a list of minimal components needed to make reproducing
>> possible. We've divided those into two groups: explicit and implicit
>> Explicit inputs are inputs from the user to the debugger.
>> - Command line arguments
>> - Settings
>> - User commands
>> - Scripting Bridge API
>> In addition to the components listed above, LLDB has a bunch of inputs
>> that are
>> not passed explicitly. It's often these that make reproducing an issue
>> - GDB Remote Packets
>> - Files containing debug information (object files, dSYM bundles)
>> - Clang headers
>> - Swift modules
>> Every component would have its own provider and is free to implement it
>> as it
>> sees fit. For example, as we expect to have a large number of GDB remote
>> packets, the provider might choose to write these to disk as they come in,
>> while the settings can easily be kept in memory until it is decided that
>> need to generate a reproducer.
>> # Concerns, Implications & Risks
>> ## Performance Impact
>> As the reproducer functionality will have to be always-on, we have to
>> performance implications. As mentioned earlier, the provider gives the
>> to be implemented in such a way that works best for its respective
>> We'll have to measure to know how big the impact is.
>> ## Privacy
>> The reproducer might contain sensitive user information. We should make it
>> clear to the user what kind of data is contained in the reproducer.
>> we will focus on the LLDB developer community and the people already
>> ## Versions
>> Because the reproducer works by replaying a debug session, the versions
>> of the
>> debugger generating an replaying the session will have to match. Not only
>> this important for the serialization format, but more importantly a
>> LLDB might ask different questions in a different order.
>> # Implementation
>> I've put up a patch (<https://reviews.llvm.org/D50254>) which contains a
>> implementation of the reproducer framework as well as the GDB remote
>> It records the GDB packets and writes them to a YAML file (we can switch
>> to a
>> more performant encoding down the road). When invoking the LLDB driver and
>> passing the reproducer directory to `--reproducer`, this file is read and
>> dummy server replies with the next packet from this file, without talking
>> the executable.
>> It's still pretty rudimentary and only works if you enter the exact same
>> commands (so the server receives the exact same requests form the client).
>> The next steps are (in broad strokes):
>> 1. Capturing the debugged binary.
>> 2. Record and replay user commands and SB-API calls.
>> 3. Recording the configuration of the debugger.
>> 4. Capturing other files used by LLDB.
>> Please let me know what you think!
>> lldb-dev mailing list
>> lldb-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev