Add StructuredData plugin type; showcase with new DarwinLog feature

[tfiala]

Summary

This change adds a new plugin-type called StructuredDataPlugin. These are detailed in depth in docs/structured_data/StructuredDataPlugins.md.

The DarwinLog feature is detailed in docs/structured_data/DarwinLog.md.

Highlights:

• StructuredData plugins are bound to a process.
• StructuredData features are advertised by the Process-derived class.
• ProcessGDBRemote sends off a query packet to ask about available features and wires up via Process if any plugins handle the feature.
• StructuredData producers (the process monitors) can send data asychronously via new $J packets, eligible to be sent while the target process is running. These packets are routed back to the plugins on the LLDB client side via the Process instance.
• DarwinLog makes use of this facility, and enables gathering and filtering new Fall 2016+ stream-based logging on Apple targets. The plugin to consume this is StructuredDataDarwinLog.cpp.

Other minor changes:

• Options and OptionsGroups now get constructed and store a pointer rather than reference to the CommandInterpreter. This facilitates reuse of the options parser without requiring the CommandInterpreter.

• debugserver will now log its internal logging through os_log() if os_log() is available on the platform and the LLDB_USE_OS_LOG=1 Xcode flag or define is set. This defaults to off except for the BuildAndIntegration configuration since it would otherwise fail to build on OS X 10.11 and earlier.

This change has been tested on:
macOS 10.12 Beta 3 + Xcode 8.0 Beta 3 (Xcode build)
macOS 10.11.5 + Xcode 7.3.1 (Xcode build)
macOS 10.12 Beta 3 (cmake build)
Ubuntu 16.04 x86_64 (cmake build)

The architecture of this change was substantially reviewed by Greg Clayton during implementation.

[tfiala]

include/lldb/Interpreter/Options.h

315 ↗

(On Diff #66172)

It is really needed. (Address-related options parsing need to do symbolication/address lookup via the target/process).

TODO: remove this comment.

[tfiala]

I talked to Jim Ingham about this. I'm going to replace the std::regex usage with the LLDB regex classes so that we don't end up using two different flavors of regex.

On the debugserver side, I'll end up needing to call the underlying regex library methods directly.

[tfiala]

The other piece Jim and I discussed was the sending over of the StructuredData configuration data in the $QConfigure{FeatureName} packet from the lldb client to the gdb-remote process monitor. That needs to be properly escaped since I'm sending over regex content that can have backslashes that are going to need escaping.

[tfiala]

Changes:

• Converts std::regex to lldb RegularExpression.

• Implements RegularExpression-like code in debugserver.

• Sends configuration data to the debug monitor in gdb-remote escaped format. This prevents the protocol from eating some of the characters that show up in regexes.

• Fix the totally broken binary decoder in debugserver. It would replace all decoded characters with the first character in the sequence so long as it wasn't an escape.

• Improve error display to user when enabling DarwinLog fails with a configuration error. Now configuration errors actually show up on the error stream for the debugger.

• Other minor bug fixes and test fixes.

[tfiala]

In D22976#501442, @tfiala wrote:

Changes:

• Converts std::regex to lldb RegularExpression.

• Implements RegularExpression-like code in debugserver.

• Sends configuration data to the debug monitor in gdb-remote escaped format. This prevents the protocol from eating some of the characters that show up in regexes.

• Fix the totally broken binary decoder in debugserver. It would replace all decoded characters with the first character in the sequence so long as it wasn't an escape.

• Improve error display to user when enabling DarwinLog fails with a configuration error. Now configuration errors actually show up on the error stream for the debugger.

• Other minor bug fixes and test fixes.

I was out on vacation last week. I'm back now. Jim had some more comments on the concept of changing options over to having optional access to the interpreter. I am going to split that part off into a separate change, put that up for review, and adjust this patch for that change.

[tfiala]

I was out on vacation last week. I'm back now. Jim had some more comments on the concept of changing options over to having optional access to the interpreter. I am going to split that part off into a separate change, put that up for review, and adjust this patch for that change.

That communication was as follows:

>8

[Jim]
One big part of this change was re-jiggering the Options so you could use them to parse your Structured Data setup options. That seems a worthy goal, but in the result you make a CommandObject's CommandOptions have to worry about not having a CommandInterpreter. That feels wrong. But it might be wrong in a different way than just "I know I always have one of these" type wrong...

So far as I can see, we need a CommandInterpreter for options in two places. One for the CommandOptions class in CommandObjectBreakpoint. The other place we use this is to run validators in Args::ParseArgs. In both cases we're only using the selected execution context, and the selected platform. It seems like it would be more straightforward to pass these in to ParseArgs, and not rely on the Options having a command interpreter at all.

This is especially true because it is a little wrong to be getting the Execution Context from the interpreter in parsing arguments for a command. We've been trying to get away from assuming that every command gets run with the ExecutionContext of the currently selected target, thread, etc... That forces us to go through changing the selected thread when we want to run stop hooks on all threads, or breakpoint commands on all the threads that hit breakpoints. We've tried to replace this with explicitly passing in the Execution Context. So this change would further that aim as well.

That's more change, but I think it is closer to right.

[Todd]
So are you thinking remove the interpreter from commands entirely, and pass in an execution context (which could be null) to the various functions on Options?

[Jim]
If possible, yes, remove the interpreter from the Options & CommandOptions.

The way we get option parsing to pick up the right Execution Context at present is a little gross. HandleCommand gets called with an ExecutionContext * (the override_context). Right away we call CommandInterpreter::UpdateExecutionContext which stores this override context away in the command interpreter. Then in a few places - processing backticks, and the argument parsing bits that need an execution context fetch the interpreter from the option, and then get the ExecutionContext from there. Seems like if we could pass the ExecutionContext directly to the few places where it was needed, then the flow would be much more explicit.

That may be more change than you want to do at this point, however.

>8

[Todd]
I will do this change, but I am going to break it into a separate stand-alone change and get that reviewed and landed first.

[tfiala]

The change to decouple Option parsing from CommandInterpreter went up for review here:
https://reviews.llvm.org/D23416

I'll refresh this patch after that.

[tfiala]

This is ready to go now.

Changes from previous:

• Removed decoupling of Options from CommandInterpreter. I did this in a separate review and commit, and I did it in a cleaner way (with ExecutionContexts).
• Added more flags to the DarwinLog enable command.
• Fixed a race in startup of the DarwinLog instrumentation when launching a process.

[clayborg]

Do we need and extra copy of JSON.h and JSON.cpp? It would be great if we can shared one between LLDB and debugserver.

docs/structured_data/StructuredDataPlugins.md

34–36

This is the case for GDB, but it won't be the case for other plug-ins. We should remove the fact that async packets can only arrive when the process is running.

38–42

Lets not mention any gdb-remote specific stuff in this document. Maybe mention how this would get plumbed through to the plug-in in terms of which virtual function will be called in the base class.

44–45

Maybe mention which virtual function gets called here?

47–50

Maybe say something like:

IDE clients might use this feature to receive information about the process as it is running to monitor memory usage, CPU usage, and logging.

65–67

I would mention this without calling out a specific plug-in.

75–76

No mention of ProcessGDBRemote?

88–94

No mention of ProcessGDBRemote? Move this to the DarwinLog docs.

include/lldb/Core/Broadcaster.h

274–279

We should probably make these bits not be the process bits and just pick examples like "eBroadcastBitOne". We shouldn't have to update this header file any time the process bits are updated.

include/lldb/Target/StructuredDataPlugin.h

28–36

I would try to agnostify this info so it doesn't mention any plug-in. We should move this text to the ProcessGDBRemote or into the DarwinLog plugin.

47

Maybe mention use cases like an IDE getting CPU usage, memory usage, etc.

source/API/SBDebugger.cpp

495–497

Remove this TODO and fix this to happen correctly in your plug-ins.

source/Core/Event.cpp

391

Are other flavor strings camel case?

source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp

386

m_qSupported_response.clear()

source/Target/Platform.cpp

1318–1343

Make sure we document the "muck with launch info" feature correctly. We should say something like "your plug-in needs to know if it is enabled, ..."

[tfiala]

Additional feedback from Jim Ingham:

• Where are the SBAPI calls to retrieve the structured data from the new process-level structured data event?

[A. Ah, yes, I neglected that. I will add in a follow-up patch. Also, I will convert at least some of the tests over to using that API instead of pexpect].

• The new Thread Plan:
  • Remove guess comments in text, they are correct.
  • Move the thread plan into source/Target. It is generally useful.

• Consider (as a change separate from this) a 'thread step-out -F {step-out-callback}' command that allows a use to call arbitrary code after the step-out completes. That could be based on the new thread plan from this change.

[jingham]

The idea seems great. I don't see how an SB client would be able to access this data? That's an oversight, the question is whether it is yours or mine?

Other little comments in-line.

docs/structured_data/StructuredDataPlugins.md

17

Maybe 'For instance, the type name of the DarwinLog feature is "DarwinLog".' would read more smoothly.

20–27

I'd remove the first sentence. It doesn't add anything, and obscures the flow which is: process monitor advertises features, process bargains with Plugins for support of the feature and installs the plugins found.

56

that -> when

64–65

When does this happen w.r.t. the publication of supported structured data features by the process monitor? This description makes it sound like plugins that might not actually be supported by the process monitor you are going to attach to get to muck with the launch info, which is a little odd.

include/lldb/Target/Process.h

3484–3485

This one doesn't have docs. Was that intentional.

include/lldb/Target/StructuredDataPlugin.h

118–122

How does this handle errors? The display below takes an error stream, for instance. Should this take an error object as a parameter?

154–157

If a plugin doesn't support enabling & disabling, then it will be always on, right? If so, perhaps this should have a default implementation that returns true.

195–196

This sounds like this initializes the debugger somehow. What does this actually do? RegisterWithDebugger or something like that?

source/Plugins/StructuredData/DarwinLog/ThreadPlanCallOnFunctionExit.cpp

116–117 ↗

(On Diff #68199)

You never run the target on your own since your plan will never be on the top of the stack when the process restarts. You will always either have the StepOut plan in front of you, or you will be done. So it doesn't actually matter what you return here.

source/Plugins/StructuredData/DarwinLog/ThreadPlanCallOnFunctionExit.h

1–11 ↗

(On Diff #68199)

This should go in source/Target, it's a generally useful plan. You might even be able to add this functionality to the extant step out plan? That's not required, after all this isn't much code, but it might make it easier to do things like extend "thread step-out" to add a completion function...

[tfiala]

First adjustment, based on Greg's feedback.

I'm not sure what to do with the broadcast bit comment. See question in my response.

I'll be putting up the patch with the adjustments covered here in a few moments.

include/lldb/Core/Broadcaster.h

274–279

I'm not sure I understand this. How would we know that eBroadcastBitOne is supposed to be a structured data event?

source/Core/Event.cpp

391

Yes, EventDataBytes in the same file uses camel case:

const ConstString &
EventDataBytes::GetFlavorString ()
{
    static ConstString g_flavor ("EventDataBytes");
    return g_flavor;
}

and

const ConstString &
Process::ProcessEventData::GetFlavorString ()
{
    static ConstString g_flavor ("Process::ProcessEventData");
    return g_flavor;
}

That highlights that perhaps the structured data should be called "Process::EventDataStructuredData", and perhaps it should really appear in Process.{h,cpp}.

source/Target/Platform.cpp

1318–1343

The RegisterPlugin call is now fully documented, including a description of responsibilities around the operation of the optional StructuredDataFilterLaunchInfo callback.

[tfiala]

Here's the patch with fixes for round one of Greg's feedback. These are primarily documentation changes.

[tfiala]

Responses and/or fixes for Jim's comments coming up in a patch momentarily.

docs/structured_data/StructuredDataPlugins.md

57

I think this change got edited out.

65–66

That's the challenge. I've added docs to the plugin registration method for StructuredDataPlugins that adds notes on the responsibilities of the optional launch info filter callback.

include/lldb/Target/Process.h

3484–3485

No, oversight. Thanks!

include/lldb/Target/StructuredDataPlugin.h

119–123

I had intended that the plugin could determine which stream it wanted to use to display output. Not so much to encode an actual error.

This is going to change, though, as I add the SBStructuredData class and the methods on it per our discussion on that.

In the old scheme, it probably made sense to just not include the stderr stream. I was being over-generous to the plugin, but the complexity addition doesn't seem to make sense for it.

155–158

Good point. Sounds fine.

196–197

I was using the same name we typically give the methods that initialize a plugin for use with a Debugger instance.

What this method actually does is makes sure that the hook points (multi-word command for the base 'plugin structured-data') is created before any single plugin child class tries to attach commands to it.

I'll try a different name here that conveys that better.

I've renamed it to:

static void
InitializeBasePluginForDebugger(Debugger &debugger);

and I documented it.

[tfiala]

Diff for previous comment.

The last change on the books to be made is to expose the StructuredData event through the SBAPI so that clients can actually react to structured data events that are raised. I'll be working on that next.

[tfiala]

• Implemented the SBAPI side of the structured data plugin system, allowing retrieval of structured data and plugin-based pretty-printing of the data.
• Converted the basic test to be event-based.
• Fixed wrong usage of a broadcast method that was skipping placing the structured data event in a listener queue if there was another structured data event in the queue. (I was using the unique-style broadcast that I mimicked from somewhere else, but that is the wrong semantics here.)

This is ready for a final review.

[jingham]

One comment inline about naming.

include/lldb/API/SBStructuredData.h

43–45

In most of the other SB API classes that produce a text version of themselves for presenting to the a user (e.g. for SBAddress, SBBreakpoint, etc) we use GetDescription as the name. Is this different enough from that to warrant a new name?

[tfiala]

In D22976#520118, @jingham wrote:

One comment inline about naming.

include/lldb/API/SBStructuredData.h

43–45

I was just using the name that I thought Greg said when we were talking about it in my office the other day.

I can switch it, although in the case of log messages, where there is formatting that is applied based on enabled options, I think this is potentially misleading. The whole reason for living of a log message is to display it. In that regard, I don't necessarily think this is the same as a typical GetDescription() method.

But I'm happy to modify it if, given my caveats above, we still think that's appropriate.

[tfiala]

• Added test base class to do event-based testing of DarwinLog support.
• Converted the regex-based message content tests to use the event-based test base class.
• Same for the basic DarwinLog test.

[tfiala]

Jim,

Okay I totally agree on the GetDescription name. I was neglecting to think that this applies to all StructuredData plugins. In that case, there is no argument to be made about a logging-focused method name.

I'm adjusting that now.

[tfiala]

Changes:

• Adjust for Jim's comment: renamed PrettyPrint(...) => GetDescription(...)
• Adjust for previous comment from Greg: remove StructuredDataPlugin::ShouldPrint(), and have the Debugger instance always do a GetDescription(...) and print it.

Hopefully the last change!

[jingham]

Looks good.

[tfiala]

Committed as r279198.

Waiting to see builders to see what happens.

[tfiala]

Something is not building now on Linux. It's been a couple weeks since I built it there and there have been enough changes since then.

I've reverted it out in r279200.

I'll get the Linux build fixed here shortly and reapply.

[tfiala]

Take 2, r279202.

Fixes:

• Missing cmake subdirectory link for source/Plugins/StructuredData.
• Return statement for default implementation of virtual was lost at some point, now restored.

[tfiala]

There's a gtest broken on this. I don't see it breaking on macOS, but I think it's because nobody is keeping the gtests updated there.

Fix coming shortly...

[tfiala]

Fixed up the gdb-remote gtest here:
r279203

I didn't see this because:

1. The Xcode lldb-gtest target has not been updated to include newer gtests.
2. The Ubuntu build process doesn't run the gtests as part of a normal build.

I need to adjust the Xcode build more - it looks like there is a depedency on libxml that didn't exist before. The macOS lldb-gtest target is broken temporarily while I fix that, but the Linux one should be fine now.

[tfiala]

r279203 fixed the gtests for the Ubuntu CI.

r279205 fixed the macOS running of gtests. The newly added Process gdb-remote gtests use some mock features that try to use RTTI. Our lldb-core explicitly builds without RTTI (via -fno-rtti), so I had to disable that for the newly-added gdb-remote gtests. I also needed to add libxml2 to the linkage.

Calling this good now.

[tfiala]

This all went in last night. The commits were noted in previous comments.

docs/structured_data/StructuredDataPlugins.md

+# Change Notes
+
+## Overview
+
+This document describes an infrastructural feature called Structured
+Data plugins.  See the DarwinLog.md doc for a description of one
+such plugin that makes use of this feature.
+
+## StructuredDataPlugin
+
+StructuredDataPlugin instances have the following characteristics:
+
+* Each plugin instance is bound to a single Process instance.
+
+* Each StructuredData feature has a type name that identifies the
+  feature. For instance, the type name for the DarwinLog feature is
+  "DarwinLog". This feature type name is used in various places.
+
+* The process monitor reports the list of supported StructuredData
+  features advertised by the process monitor. Process goes through the
+  list of supported feature type names, and asks each known
+  StructuredDataPlugin if it can handle the feature. The first plugin
+  that supports the feature is mapped to that Process instance for
+  that feature.  Plugins are only mapped when the process monitor
+  advertises that a feature is supported.
+
+* The feature may send asynchronous messages in StructuredData format
+  to the Process instance. Process instances route the asynchronous
+  structured data messages to the plugin mapped to that feature type,
+  if one exists.
+
+* Plugins can request that the Process instance forward on
+  configuration data to the process monitor if the plugin needs/wants
+  to configure the feature. Plugins may call the new Process method
+
+  ```C++
+  virtual Error
+  ConfigureStructuredData(const ConstString &type_name,
+                          const StructuredData::ObjectSP &config_sp)
+  ```
+
+  where type_name is the feature name and config_sp points to the
+  configuration structured data, which may be nullptr.
+
+* Plugins for features present in a process are notified when modules
+  are loaded into the Process instance via this StructuredDataPlugin
+  method:
+
+  ```C++
+  virtual void
+  ModulesDidLoad(Process &process, ModuleList &module_list);
+  ```
+
+* Plugins may optionally broadcast their received structured data as
+  an LLDB process-level event via the following new Process call:
+
+  ```C++
+  void
+  BroadcastStructuredData(const StructuredData::ObjectSP &object_sp,
+                          const lldb::StructuredDataPluginSP &plugin_sp);
+  ```
+
+  IDE clients might use this feature to receive information about the
+  process as it is running to monitor memory usage, CPU usage, and
+  logging.
+
+  Internally, the event type created is an instance of
+  EventDataStructuredData.
+
+* In the case where a plugin chooses to broadcast a received
+  StructuredData event, the command-line LLDB Debugger instance
+  listens for them. The Debugger instance then gives the plugin an
+  opportunity to display info to either the debugger output or error
+  stream at a time that is safe to write to them. The plugin can
+  choose to display something appropriate regarding the structured
+  data that time.
+
+* Plugins can provide a ProcessLaunchInfo filter method when the
+  plugin is registered.  If such a filter method is provided, then
+  when a process is about to be launched for debugging, the filter
+  callback is invoked, given both the launch info and the target.  The
+  plugin may then alter the launch info if needed to better support
+  the feature of the plugin.
+
+* The plugin is entirely independent of the type of Process-derived
+  class that it is working with. The only requirements from the
+  process monitor are the following feature-agnostic elements:
+
+  * Provide a way to discover features supported by the process
+    monitor for the current process.
+
+  * Specify the list of supported feature type names to Process.
+    The process monitor does this by calling the following new
+    method on Process:
+
+    ```C++
+    void
+    MapSupportedStructuredDataPlugins(const StructuredData::Array
+                                      &supported_type_names)
+    ```
+
+    The supported_type_names specifies an array of string entries,
+    where each entry specifies the name of a StructuredData feature.
+
+  * Provide a way to forward on configuration data for a feature type
+    to the process monitor.  This is the manner by which LLDB can
+    configure a feature, perhaps based on settings or commands from
+    the user.  The following virtual method on Process (described
+    earlier) does the job:
+
+    ```C++
+    virtual Error
+    ConfigureStructuredData(const ConstString &type_name,
+                            const StructuredData::ObjectSP &config_sp)
+    ```
+
+  * Listen for asynchronous structured data packets from the process
+    monitor, and forward them on to Process via this new Process
+    member method:
+
+    ```C++
+    bool
+    RouteAsyncStructuredData(const StructuredData::ObjectSP object_sp)
+    ```
+
+* StructuredData producers must send their top-level data as a
+  Dictionary type, with a key called 'type' specifying a string value,
+  where the value is equal to the StructuredData feature/type name
+  previously advertised. Everything else about the content of the
+  dictionary is entirely up to the feature.
+
+* StructuredDataPlugin commands show up under 'plugin structured-data
+  plugin-name'.
+
+* StructuredDataPlugin settings show up under
+  'plugin.structured-data.{plugin-name}.

include/lldb/API/SBStructuredData.h

+//===-- SBStructuredData.h --------------------------------------*- C++ -*-===//
+//
+//                     The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef SBStructuredData_h
+#define SBStructuredData_h
+
+#include "lldb/API/SBDefines.h"
+#include "lldb/API/SBModule.h"
+
+namespace lldb {
+
+    class SBStructuredData
+    {
+    public:
+
+        SBStructuredData();
+
+        SBStructuredData(const lldb::SBStructuredData &rhs);
+
+        SBStructuredData(const lldb::EventSP &event_sp);
+
+        ~SBStructuredData();
+
+        lldb::SBStructuredData &
+        operator =(const lldb::SBStructuredData &rhs);
+
+        bool
+        IsValid() const;
+
+        void
+        Clear();
+
+        lldb::SBError
+        GetAsJSON(lldb::SBStream &stream) const;
+
+        lldb::SBError
+        GetDescription(lldb::SBStream &stream) const;
+
+    private:
+
+        class Impl;
+        std::unique_ptr<Impl> m_impl_up;
+    };
+}
+
+#endif /* SBStructuredData_h */

include/lldb/Core/Broadcaster.h

 ///     \code
 ///         class Foo : public Broadcaster
 ///         {
 ///         public:
 ///         //----------------------------------------------------------
 ///         // Broadcaster event bits definitions.
 ///         //----------------------------------------------------------
 ///         enum
 ///         {
-///             eBroadcastBitStateChanged   = (1 << 0),
-///             eBroadcastBitInterrupt      = (1 << 1),
-///             eBroadcastBitSTDOUT         = (1 << 2),
-///             eBroadcastBitSTDERR         = (1 << 3),
-///             eBroadcastBitProfileData    = (1 << 4)
+///             eBroadcastBitOne   = (1 << 0),
+///             eBroadcastBitTwo   = (1 << 1),
+///             eBroadcastBitThree = (1 << 2),
+///             ...
 ///         };
 ///     \endcode
 //----------------------------------------------------------------------
 class Broadcaster
 {
 friend class Listener;
 friend class Event;
 public:
     //------------------------------------------------------------------

include/lldb/Target/Process.h

public:
     /// Broadcaster event bits definitions.
     //------------------------------------------------------------------
     enum
     {
         eBroadcastBitStateChanged   = (1 << 0),
         eBroadcastBitInterrupt      = (1 << 1),
         eBroadcastBitSTDOUT         = (1 << 2),
         eBroadcastBitSTDERR         = (1 << 3),
-        eBroadcastBitProfileData    = (1 << 4)
+        eBroadcastBitProfileData    = (1 << 4),
+        eBroadcastBitStructuredData = (1 << 5),
     };
 
     enum
     {
         eBroadcastInternalStateControlStop = (1<<0),
         eBroadcastInternalStateControlPause = (1<<1),
         eBroadcastInternalStateControlResume = (1<<2)
     };

     ///     the range provided in range_bounds.  If there are any
     ///     problems with the disassembly or getting the instructions,
     ///     the original default_stop_addr will be returned.
     //------------------------------------------------------------------
     Address
     AdvanceAddressToNextBranchInstruction (Address default_stop_addr, 
                                            AddressRange range_bounds);
 
+    //------------------------------------------------------------------
+    /// Configure asynchronous structured data feature.
+    ///
+    /// Each Process type that supports using an asynchronous StructuredData
+    /// feature should implement this to enable/disable/configure the feature.
+    /// The default implementation here will always return an error indiciating
+    /// the feature is unsupported.
+    ///
+    /// StructuredDataPlugin implementations will call this to configure
+    /// a feature that has been reported as being supported.
+    ///
+    /// @param[in] type_name
+    ///     The StructuredData type name as previously discovered by
+    ///     the Process-derived instance.
+    ///
+    /// @param[in] config
+    ///     Configuration data for the feature being enabled.  This config
+    ///     data, which may be null, will be passed along to the feature
+    ///     to process.  The feature will dictate whether this is a dictionary,
+    ///     an array or some other object.  If the feature needs to be
+    ///     set up properly before it can be enabled, then the config should
+    ///     also take an enable/disable flag.
+    ///
+    /// @return
+    ///     Returns the result of attempting to configure the feature.
+    //------------------------------------------------------------------
+    virtual Error
+    ConfigureStructuredData(const ConstString &type_name,
+                            const StructuredData::ObjectSP &config_sp);
+
+    //------------------------------------------------------------------
+    /// Broadcasts the given structured data object from the given
+    /// plugin.
+    ///
+    /// StructuredDataPlugin instances can use this to optionally
+    /// broadcast any of their data if they want to make it available
+    /// for clients.  The data will come in on the structured data
+    /// event bit (eBroadcastBitStructuredData).
+    ///
+    /// @param[in] object_sp
+    ///     The structured data object to broadcast.
+    ///
+    /// @param[in] plugin_sp
+    ///     The plugin that will be reported in the event's plugin
+    ///     parameter.
+    //------------------------------------------------------------------
+    void
+    BroadcastStructuredData(const StructuredData::ObjectSP &object_sp,
+                            const lldb::StructuredDataPluginSP &plugin_sp);
+
+    //------------------------------------------------------------------
+    /// Returns the StructuredDataPlugin associated with a given type
+    /// name, if there is one.
+    ///
+    /// There will only be a plugin for a given StructuredDataType if the
+    /// debugged process monitor claims that the feature is supported.
+    /// This is one way to tell whether a feature is available.
+    ///
+    /// @return
+    ///     The plugin if one is available for the specified feature;
+    ///     otherwise, returns an empty shared pointer.
+    //------------------------------------------------------------------
+    lldb::StructuredDataPluginSP
+    GetStructuredDataPlugin(const ConstString &type_name) const;
+
 protected:
     void
     SetState (lldb::EventSP &event_sp);
 
     lldb::StateType
     GetPrivateState ();
 
     //------------------------------------------------------------------
protected:
 
     void
     ForceNextEventDelivery()
     {
         m_force_next_event_delivery = true;
     }
 
     //------------------------------------------------------------------
+    /// Loads any plugins associated with asynchronous structured data
+    /// and maps the relevant supported type name to the plugin.
+    ///
+    /// Processes can receive asynchronous structured data from the
+    /// process monitor.  This method will load and map any structured
+    /// data plugins that support the given set of supported type names.
+    /// Later, if any of these features are enabled, the process monitor
+    /// is free to generate asynchronous structured data.  The data must
+    /// come in as a single \b StructuredData::Dictionary.  That dictionary
+    /// must have a string field named 'type', with a value that equals
+    /// the relevant type name string (one of the values in
+    /// \b supported_type_names).
+    ///
+    /// @param[in] supported_type_names
+    ///     An array of zero or more type names.  Each must be unique.
+    ///     For each entry in the list, a StructuredDataPlugin will be
+    ///     searched for that supports the structured data type name.
+    //------------------------------------------------------------------
+    void
+    MapSupportedStructuredDataPlugins(const StructuredData::Array
+                                           &supported_type_names);
+
+    //------------------------------------------------------------------
+    /// Route the incoming structured data dictionary to the right plugin.
+    ///
+    /// The incoming structured data must be a dictionary, and it must
+    /// have a key named 'type' that stores a string value.  The string
+    /// value must be the name of the structured data feature that
+    /// knows how to handle it.
+    ///
+    /// @param[in] object_sp
+    ///     When non-null and pointing to a dictionary, the 'type'
+    ///     key's string value is used to look up the plugin that
+    ///     was registered for that structured data type.  It then
+    ///     calls the following method on the StructuredDataPlugin
+    ///     instance:
+    ///
+    ///     virtual void
+    ///     HandleArrivalOfStructuredData(Process &process,
+    ///                                   const ConstString &type_name,
+    ///                                   const StructuredData::ObjectSP
+    ///                                   &object_sp)
+    ///
+    /// @return
+    ///     True if the structured data was routed to a plugin; otherwise,
+    ///     false.
+    //------------------------------------------------------------------
+    bool
+    RouteAsyncStructuredData(const StructuredData::ObjectSP object_sp);
+
+    //------------------------------------------------------------------
     // Type definitions
     //------------------------------------------------------------------
     typedef std::map<lldb::LanguageType, lldb::LanguageRuntimeSP> LanguageRuntimeCollection;
     typedef std::unordered_set<const void *> WarningsPointerSet;
     typedef std::map<uint64_t, WarningsPointerSet> WarningsCollection;
 
     struct PreResumeCallbackAndBaton
     {
         bool (*callback) (void *);
         void *baton;
         PreResumeCallbackAndBaton (PreResumeActionCallback in_callback, void *in_baton) :
             callback (in_callback),
             baton (in_baton)
         {
         }
     };
-    
+    using StructuredDataPluginMap = std::map<ConstString,
+                                             lldb::StructuredDataPluginSP>;
+    
     //------------------------------------------------------------------
     // Member variables
     //------------------------------------------------------------------
     std::weak_ptr<Target>       m_target_sp;            ///< The target that owns this process.
     ThreadSafeValue<lldb::StateType>  m_public_state;
     ThreadSafeValue<lldb::StateType>  m_private_state; // The actual state of our process
     Broadcaster                 m_private_state_broadcaster;  // This broadcaster feeds state changed events into the private state thread's listener.
     Broadcaster                 m_private_state_control_broadcaster; // This is the control broadcaster, used to pause, resume & stop the private state thread.
protected:
     bool                        m_clear_thread_plans_on_stop;
     bool                        m_force_next_event_delivery;
     lldb::StateType             m_last_broadcast_state;   /// This helps with the Public event coalescing in ShouldBroadcastEvent.
     std::map<lldb::addr_t,lldb::addr_t> m_resolved_indirect_addresses;
     bool m_destroy_in_process;
     bool m_can_interpret_function_calls; // Some targets, e.g the OSX kernel, don't support the ability to modify the stack.
     WarningsCollection          m_warnings_issued;  // A set of object pointers which have already had warnings printed
     std::mutex                  m_run_thread_plan_lock;
-    
+    StructuredDataPluginMap     m_structured_data_plugin_map;
+
     enum {
         eCanJITDontKnow= 0,
         eCanJITYes,
         eCanJITNo
     } m_can_jit;
 
     size_t
     RemoveBreakpointOpcodesFromBuffer (lldb::addr_t addr, size_t size, uint8_t *buf) const;
protected:
     void
     AppendSTDOUT (const char *s, size_t len);
     
     void
     AppendSTDERR (const char *s, size_t len);
     
     void
     BroadcastAsyncProfileData(const std::string &one_profile_data);
-    
     static void
     STDIOReadThreadBytesReceived (void *baton, const void *src, size_t src_len);
     
     bool
     PushProcessIOHandler ();
     
     bool
     PopProcessIOHandler ();

include/lldb/Target/StructuredDataPlugin.h

+//===-- StructuredDataPlugin.h ----------------------------------*- C++ -*-===//
+//
+//                     The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef StructuredDataPlugin_h
+#define StructuredDataPlugin_h
+
+#include "lldb/Core/PluginInterface.h"
+#include "lldb/Core/StructuredData.h"
+
+namespace lldb_private
+{
+
+class CommandObjectMultiword;
+
+// -----------------------------------------------------------------------------
+/// Plugin that supports process-related structured data sent asynchronously
+/// from the debug monitor (e.g. debugserver, lldb-server, etc.)
+///
+/// This plugin type is activated by a Process-derived instance when that
+/// instance detects that a given structured data feature is available.
+///
+/// StructuredDataPlugin instances are inherently tied to a process.  The
+/// main functionality they support is the ability to consume asynchronously-
+/// delivered structured data from the process monitor, and do something
+/// reasonable with it.  Something reasonable can include broadcasting a
+/// StructuredData event, which other parts of the system can then do with
+/// as they please.  An IDE could use this facility to retrieve CPU usage,
+/// memory usage, and other run-time aspects of the process.  That data
+/// can then be displayed meaningfully to the user through the IDE.
+
+/// For command-line LLDB, the Debugger instance listens for the structured
+/// data events raised by the plugin, and give the plugin both the output
+/// and error streams such that the plugin can display something about the
+/// event, at a time when the debugger ensures it is safe to write to the
+/// output or error streams.
+// -----------------------------------------------------------------------------
+
+class StructuredDataPlugin :
+    public PluginInterface,
+    public std::enable_shared_from_this<StructuredDataPlugin>
+{
+public:
+
+    virtual ~StructuredDataPlugin();
+
+    lldb::ProcessSP
+    GetProcess() const;
+
+    // -------------------------------------------------------------------------
+    // Public instance API
+    // -------------------------------------------------------------------------
+
+    // -------------------------------------------------------------------------
+    /// Return whether this plugin supports the given StructuredData feature.
+    ///
+    /// When Process is informed of a list of process-monitor-supported
+    /// structured data features, Process will go through the list of plugins,
+    /// one at a time, and have the first plugin that supports a given feature
+    /// be the plugin instantiated to handle that feature.  There is a 1-1
+    /// correspondence between a Process instance and a StructuredDataPlugin
+    /// mapped to that process.  A plugin can support handling multiple
+    /// features, and if that happens, there is a single plugin instance
+    /// created covering all of the mapped features for a given process.
+    ///
+    /// @param[in] type_name
+    ///     The name of the feature tag supported by a process.
+    ///     e.g. "darwin-log".
+    ///
+    /// @return
+    ///     true if the plugin supports the feature; otherwise, false.
+    // -------------------------------------------------------------------------
+    virtual bool
+    SupportsStructuredDataType(const ConstString &type_name) = 0;
+
+    // -------------------------------------------------------------------------
+    /// Handle the arrival of asynchronous structured data from the process.
+    ///
+    /// When asynchronous structured data arrives from the process monitor,
+    /// it is immediately delivered to the plugin mapped for that feature
+    /// if one exists.  The structured data that arrives from a process
+    /// monitor must be a dictionary, and it must have a string field named
+    /// "type" that must contain the StructuredData feature name set as the
+    /// value.  This is the manner in which the data is routed to the proper
+    /// plugin instance.
+    ///
+    /// @param[in] process
+    ///     The process instance that just received the structured data.
+    ///     This will always be the same process for a given instance of
+    ///     a plugin.
+    ///
+    /// @param[in] type_name
+    ///     The name of the feature tag for the asynchronous structured data.
+    ///     Note this data will also be present in the \b object_sp dictionary
+    ///     under the string value with key "type".
+    ///
+    /// @param[in] object_sp
+    ///     A shared pointer to the structured data that arrived.  This must
+    ///     be a dictionary.  The only key required is the aforementioned
+    ///     key named "type" that must be a string value containing the
+    ///     structured data type name.
+    // -------------------------------------------------------------------------
+    virtual void
+    HandleArrivalOfStructuredData(Process &process,
+                                  const ConstString &type_name,
+                                  const StructuredData::ObjectSP
+                                  &object_sp) = 0;
+
+
+    // -------------------------------------------------------------------------
+    /// Get a human-readable description of the contents of the data.
+    ///
+    /// In command-line LLDB, this method will be called by the Debugger
+    /// instance for each structured data event generated, and the output
+    /// will be printed to the LLDB console.  If nothing is added to the stream,
+    /// nothing will be printed; otherwise, a newline will be added to the end
+    /// when displayed.
+    ///
+    /// @param[in] object_sp
+    ///     A shared pointer to the structured data to format.
+    ///
+    /// @param[in] stream
+    ///     The stream where the structured data should be pretty printed.
+    ///
+    /// @return
+    ///     The error if formatting the object contents failed; otherwise,
+    ///     success.
+    // -------------------------------------------------------------------------
+    virtual Error
+    GetDescription(const StructuredData::ObjectSP &object_sp,
+                   lldb_private::Stream &stream) = 0;
+
+    // -------------------------------------------------------------------------
+    /// Returns whether the plugin's features are enabled.
+    ///
+    /// This is a convenience method for plugins that can enable or disable
+    /// their functionality.  It allows retrieval of this state without
+    /// requiring a cast.
+    ///
+    /// @param[in] type_name
+    ///     The name of the feature tag for the asynchronous structured data.
+    ///     This is needed for plugins that support more than one feature.
+    // -------------------------------------------------------------------------
+    virtual bool
+    GetEnabled(const ConstString &type_name) const;
+
+    // -------------------------------------------------------------------------
+    /// Allow the plugin to do work related to modules that loaded in the
+    /// the corresponding process.
+    ///
+    /// This method defaults to doing nothing.  Plugins can override it
+    /// if they have any behavior they want to enable/modify based on loaded
+    /// modules.
+    ///
+    /// @param[in] process
+    ///     The process that just was notified of modules having been loaded.
+    ///     This will always be the same process for a given instance of
+    ///     a plugin.
+    ///
+    /// @param[in] module_list
+    ///     The list of modules that the process registered as having just
+    ///     loaded.  See \b Process::ModulesDidLoad(...).
+    // -------------------------------------------------------------------------
+    virtual void
+    ModulesDidLoad(Process &process, ModuleList &module_list);
+
+protected:
+
+    // -------------------------------------------------------------------------
+    // Derived-class API
+    // -------------------------------------------------------------------------
+    StructuredDataPlugin(const lldb::ProcessWP &process_wp);
+
+    // -------------------------------------------------------------------------
+    /// Derived classes must call this before attempting to hook up commands
+    /// to the 'plugin structured-data' tree.
+    ///
+    /// This ensures the relevant command and options hook points for all
+    /// StructuredDataPlugin derived classes are available for this debugger.
+    /// If this has already happened, this call is a no-op.
+    ///
+    /// @param[in] debugger
+    ///     The Debugger instance for which we're creating the required shared
+    ///     components for the StructuredDataPlugin derived classes.
+    // -------------------------------------------------------------------------
+    static void
+    InitializeBasePluginForDebugger(Debugger &debugger);
+
+private:
+
+    lldb::ProcessWP m_process_wp;
+
+    DISALLOW_COPY_AND_ASSIGN(StructuredDataPlugin);
+
+};
+
+}
+
+#endif

source/API/SBDebugger.cpp

SBDebugger::HandleProcessEvent (const SBProcess &process, const SBEvent &event, FILE *out, FILE *err)
     
     if (event_type & (Process::eBroadcastBitSTDERR | Process::eBroadcastBitStateChanged))
     {
         // Drain stderr when we stop just in case we have any bytes
         while ((len = process.GetSTDERR (stdio_buffer, sizeof (stdio_buffer))) > 0)
             if (err != nullptr)
                 ::fwrite (stdio_buffer, 1, len, err);
     }
-    
     if (event_type & Process::eBroadcastBitStateChanged)
     {
         StateType event_state = SBProcess::GetStateFromEvent (event);
         
         if (event_state == eStateInvalid)
             return;
         
         bool is_stopped = StateIsStoppedState (event_state);
         if (!is_stopped)
             process.ReportEventState (event, out);
     }

source/Core/Event.cpp

 #include "lldb/Core/State.h"
 #include "lldb/Core/Stream.h"
 #include "lldb/Host/Endian.h"
 #include "lldb/Target/Process.h"
 
 using namespace lldb;
 using namespace lldb_private;
 
+#pragma mark -
+#pragma mark Event
+
+//------------------------------------------------------------------
+// Event functions
+//------------------------------------------------------------------
+
 Event::Event (Broadcaster *broadcaster, uint32_t event_type, EventData *data) :
     m_broadcaster_wp(broadcaster->GetBroadcasterImpl()),
     m_type(event_type),
     m_data_sp(data)
 {
 }
 
 Event::Event (Broadcaster *broadcaster, uint32_t event_type, const EventDataSP &event_data_sp) :

 
 void
 Event::DoOnRemoval ()
 {
     if (m_data_sp)
         m_data_sp->DoOnRemoval (this);
 }
 
+#pragma mark -
+#pragma mark EventData
+
+//------------------------------------------------------------------
+// EventData functions
+//------------------------------------------------------------------
+
 EventData::EventData() = default;
 
 EventData::~EventData() = default;
 
 void
 EventData::Dump (Stream *s) const
 {
     s->PutCString ("Generic Event Data");
 }
 
+#pragma mark -
+#pragma mark EventDataBytes
+
+//------------------------------------------------------------------
+// EventDataBytes functions
+//------------------------------------------------------------------
+
+
 EventDataBytes::EventDataBytes () :
     m_bytes()
 {
 }
 
 EventDataBytes::EventDataBytes (const char *cstr) :
     m_bytes()
 {
EventDataBytes::GetEventDataFromEvent (const Event *event_ptr)
     return nullptr;
 }
 
 void
 EventDataBytes::SwapBytes (std::string &new_bytes)
 {
     m_bytes.swap (new_bytes);
 }
+
+#pragma mark -
+#pragma mark EventStructuredData
+
+//------------------------------------------------------------------
+// EventDataStructuredData definitions
+//------------------------------------------------------------------
+
+EventDataStructuredData::EventDataStructuredData() :
+    EventData(),
+    m_process_sp(),
+    m_object_sp(),
+    m_plugin_sp()
+{
+}
+
+EventDataStructuredData::EventDataStructuredData(const ProcessSP &process_sp,
+                                                 const StructuredData::ObjectSP
+                                                 &object_sp,
+                                                 const
+                                                 lldb::StructuredDataPluginSP
+                                                 &plugin_sp) :
+    EventData(),
+    m_process_sp(process_sp),
+    m_object_sp(object_sp),
+    m_plugin_sp(plugin_sp)
+{
+}
+
+EventDataStructuredData::~EventDataStructuredData()
+{
+}
+
+//------------------------------------------------------------------
+// EventDataStructuredData member functions
+//------------------------------------------------------------------
+
+const ConstString &
+EventDataStructuredData::GetFlavor() const
+{
+    return EventDataStructuredData::GetFlavorString();
+}
+
+void
+EventDataStructuredData::Dump(Stream *s) const
+{
+    if (!s)
+        return;
+
+    if (m_object_sp)
+        m_object_sp->Dump(*s);
+}
+
+const ProcessSP&
+EventDataStructuredData::GetProcess() const
+{
+    return m_process_sp;
+}
+
+const StructuredData::ObjectSP&
+EventDataStructuredData::GetObject() const
+{
+    return m_object_sp;
+}
+
+const lldb::StructuredDataPluginSP&
+EventDataStructuredData::GetStructuredDataPlugin() const
+{
+    return m_plugin_sp;
+}
+
+void
+EventDataStructuredData::SetProcess(const ProcessSP &process_sp)
+{
+    m_process_sp = process_sp;
+}
+
+void
+EventDataStructuredData::SetObject(const StructuredData::ObjectSP &object_sp)
+{
+    m_object_sp = object_sp;
+}
+
+void
+EventDataStructuredData::SetStructuredDataPlugin(const
+                                                 lldb::StructuredDataPluginSP
+                                                 &plugin_sp)
+{
+    m_plugin_sp = plugin_sp;
+}
+
+//------------------------------------------------------------------
+// EventDataStructuredData static functions
+//------------------------------------------------------------------
+
+const EventDataStructuredData*
+EventDataStructuredData::GetEventDataFromEvent(const Event *event_ptr)
+{
+    if (event_ptr == nullptr)
+        return nullptr;
+
+    const EventData *event_data = event_ptr->GetData();
+    if (!event_data || event_data->GetFlavor() !=
+        EventDataStructuredData::GetFlavorString())
+        return nullptr;
+
+    return static_cast<const EventDataStructuredData*>(event_data);
+}
+
+ProcessSP
+EventDataStructuredData::GetProcessFromEvent(const Event *event_ptr)
+{
+    auto event_data = EventDataStructuredData::GetEventDataFromEvent(event_ptr);
+    if (event_data)
+        return event_data->GetProcess();
+    else
+        return ProcessSP();
+}
+
+StructuredData::ObjectSP
+EventDataStructuredData::GetObjectFromEvent(const Event *event_ptr)
+{
+    auto event_data = EventDataStructuredData::GetEventDataFromEvent(event_ptr);
+    if (event_data)
+        return event_data->GetObject();
+    else
+        return StructuredData::ObjectSP();
+}
+
+lldb::StructuredDataPluginSP
+EventDataStructuredData::GetPluginFromEvent(const Event *event_ptr)
+{
+    auto event_data = EventDataStructuredData::GetEventDataFromEvent(event_ptr);
+    if (event_data)
+        return event_data->GetStructuredDataPlugin();
+    else
+        return StructuredDataPluginSP();
+}
+
+const ConstString &
+EventDataStructuredData::GetFlavorString ()
+{
+    static ConstString s_flavor("EventDataStructuredData");
+    return s_flavor;
+}
+
+

source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp

 #include "lldb/Core/StreamGDBRemote.h"
 #include "lldb/Core/StreamString.h"
 #include "lldb/Host/HostInfo.h"
 #include "lldb/Host/StringConvert.h"
 #include "lldb/Host/TimeValue.h"
 #include "lldb/Interpreter/Args.h"
 #include "lldb/Symbol/Symbol.h"
 #include "lldb/Target/MemoryRegionInfo.h"
+#include "lldb/Target/UnixSignals.h"
+#include "lldb/Utility/LLDBAssert.h"
 #include "lldb/Target/Target.h"
 
 // Project includes
 #include "Utility/StringExtractorGDBRemote.h"
 #include "ProcessGDBRemote.h"
 #include "ProcessGDBRemoteLog.h"
 #include "lldb/Host/Config.h"
 
: GDBRemoteClientBase("gdb-remote.client", "gdb-remote.client.rx_packet"),
       m_os_version_minor(UINT32_MAX),
       m_os_version_update(UINT32_MAX),
       m_os_build(),
       m_os_kernel(),
       m_hostname(),
       m_gdb_server_name(),
       m_gdb_server_version(UINT32_MAX),
       m_default_packet_timeout(0),
-      m_max_packet_size(0)
+      m_max_packet_size(0),
+      m_qSupported_response(),
+      m_supported_async_json_packets_is_valid(false),
+      m_supported_async_json_packets_sp()
 {
 }
 
 //----------------------------------------------------------------------
 // Destructor
 //----------------------------------------------------------------------
 GDBRemoteCommunicationClient::~GDBRemoteCommunicationClient()
 {
if (did_exec == false)
         m_os_version_update = UINT32_MAX;
         m_os_build.clear();
         m_os_kernel.clear();
         m_hostname.clear();
         m_gdb_server_name.clear();
         m_gdb_server_version = UINT32_MAX;
         m_default_packet_timeout = 0;
         m_max_packet_size = 0;
+        m_qSupported_response.clear();
+        m_supported_async_json_packets_is_valid = false;
+        m_supported_async_json_packets_sp.reset();
     }
 
     // These flags should be reset when we first connect to a GDB server
     // and when our inferior process execs
     m_qProcessInfo_is_valid = eLazyBoolCalculate;
     m_process_arch.Clear();
 }
 
GDBRemoteCommunicationClient::GetRemoteQSupported ()
     }
 
     StringExtractorGDBRemote response;
     if (SendPacketAndWaitForResponse(packet.GetData(),
                                      response,
                                      /*send_async=*/false) == PacketResult::Success)
     {
         const char *response_cstr = response.GetStringRef().c_str();
+
+        // Hang on to the qSupported packet, so that platforms can do custom
+        // configuration of the transport before attaching/launching the
+        // process.
+        m_qSupported_response = response_cstr;
+
         if (::strstr (response_cstr, "qXfer:auxv:read+"))
             m_supports_qXfer_auxv_read = eLazyBoolYes;
         if (::strstr (response_cstr, "qXfer:libraries-svr4:read+"))
             m_supports_qXfer_libraries_svr4_read = eLazyBoolYes;
         if (::strstr (response_cstr, "augmented-libraries-svr4-read"))
         {
             m_supports_qXfer_libraries_svr4_read = eLazyBoolYes;  // implied
             m_supports_augmented_libraries_svr4_read = eLazyBoolYes;
if (m_supports_qSymbol && m_qSymbol_requests_done == false)
         }
         else if (Log *log = ProcessGDBRemoteLog::GetLogIfAnyCategoryIsSet(GDBR_LOG_PROCESS | GDBR_LOG_PACKETS))
         {
             log->Printf("GDBRemoteCommunicationClient::%s: Didn't get sequence mutex.", __FUNCTION__);
         }
     }
 }
 
+StructuredData::Array*
+GDBRemoteCommunicationClient::GetSupportedStructuredDataPlugins()
+{
+    if (!m_supported_async_json_packets_is_valid)
+    {
+        // Query the server for the array of supported asynchronous JSON
+        // packets.
+        m_supported_async_json_packets_is_valid = true;
+
+        Log *log(ProcessGDBRemoteLog::GetLogIfAllCategoriesSet(
+            GDBR_LOG_PROCESS));
+
+        // Poll it now.
+        StringExtractorGDBRemote response;
+        const bool send_async = false;
+        if (SendPacketAndWaitForResponse("qStructuredDataPlugins", response,
+                                         send_async) == PacketResult::Success)
+        {
+            m_supported_async_json_packets_sp = StructuredData::ParseJSON(
+                response.GetStringRef());
+            if (m_supported_async_json_packets_sp &&
+                !m_supported_async_json_packets_sp->GetAsArray())
+            {
+                // We were returned something other than a JSON array.  This
+                // is invalid.  Clear it out.
+                if (log)
+                    log->Printf("GDBRemoteCommunicationClient::%s(): "
+                                "QSupportedAsyncJSONPackets returned invalid "
+                                "result: %s", __FUNCTION__,
+                                response.GetStringRef().c_str());
+                m_supported_async_json_packets_sp.reset();
+            }
+        }
+        else
+        {
+            if (log)
+                log->Printf("GDBRemoteCommunicationClient::%s(): "
+                            "QSupportedAsyncJSONPackets unsupported",
+                            __FUNCTION__);
+        }
+
+        if (log && m_supported_async_json_packets_is_valid)
+        {
+            StreamString  stream;
+            m_supported_async_json_packets_sp->Dump(stream);
+            log->Printf("GDBRemoteCommunicationClient::%s(): supported async "
+                        "JSON packets: %s", __FUNCTION__,
+                        stream.GetString().c_str());
+        }
+    }
+
+    return m_supported_async_json_packets_sp
+        ? m_supported_async_json_packets_sp->GetAsArray()
+        : nullptr;
+}
+
+Error
+GDBRemoteCommunicationClient::ConfigureRemoteStructuredData(
+    const ConstString &type_name,
+    const StructuredData::ObjectSP &config_sp)
+{
+    Error error;
+
+    if (type_name.GetLength() == 0)
+    {
+        error.SetErrorString("invalid type_name argument");
+        return error;
+    }
+
+    // Build command: Configure{type_name}: serialized config
+    // data.
+    StreamGDBRemote stream;
+    stream.PutCString("QConfigure");
+    stream.PutCString(type_name.AsCString());
+    stream.PutChar(':');
+    if (config_sp)
+    {
+        // Gather the plain-text version of the configuration data.
+        StreamString unescaped_stream;
+        config_sp->Dump(unescaped_stream);
+        unescaped_stream.Flush();
+
+        // Add it to the stream in escaped fashion.
+        stream.PutEscapedBytes(unescaped_stream.GetData(),
+                               unescaped_stream.GetSize());
+    }
+    stream.Flush();
+
+    // Send the packet.
+    const bool send_async = false;
+    StringExtractorGDBRemote response;
+    auto result = SendPacketAndWaitForResponse(stream.GetString().c_str(),
+                                               response, send_async);
+    if (result == PacketResult::Success)
+    {
+        // We failed if the config result comes back other than OK.
+        if (strcmp(response.GetStringRef().c_str(), "OK") == 0)
+        {
+            // Okay!
+            error.Clear();
+        }
+        else
+        {
+            error.SetErrorStringWithFormat("configuring StructuredData feature "
+                                           "%s failed with error %s",
+                                           type_name.AsCString(),
+                                           response.GetStringRef().c_str());
+        }
+    }
+    else
+    {
+        // Can we get more data here on the failure?
+        error.SetErrorStringWithFormat("configuring StructuredData feature %s "
+                                       "failed when sending packet: "
+                                       "PacketResult=%d", type_name.AsCString(),
+                                       result);
+    }
+    return error;
+}
+
 void
 GDBRemoteCommunicationClient::OnRunPacketSent(bool first)
 {
     GDBRemoteClientBase::OnRunPacketSent(first);
     m_curr_tid = LLDB_INVALID_THREAD_ID;
 }

source/Target/Platform.cpp

Platform::DebugProcess (ProcessLaunchInfo &launch_info,
 
     ProcessSP process_sp;
     // Make sure we stop at the entry point
     launch_info.GetFlags ().Set (eLaunchFlagDebug);
     // We always launch the process we are going to debug in a separate process
     // group, since then we can handle ^C interrupts ourselves w/o having to worry
     // about the target getting them as well.
     launch_info.SetLaunchInSeparateProcessGroup(true);
-    
+    // Allow any StructuredData process-bound plugins to adjust the launch info
+    // if needed
+    size_t i = 0;
+    bool iteration_complete = false;
+    // Note iteration can't simply go until a nullptr callback is returned, as
+    // it is valid for a plugin to not supply a filter.
+    auto get_filter_func =
+        PluginManager::GetStructuredDataFilterCallbackAtIndex;
+    for (auto filter_callback = get_filter_func(i, iteration_complete);
+         !iteration_complete;
+         filter_callback = get_filter_func(++i, iteration_complete))
+    {
+        if (filter_callback)
+        {
+            // Give this ProcessLaunchInfo filter a chance to adjust the launch
+            // info.
+            error = (*filter_callback)(launch_info, target);
+            if (!error.Success())
+            {
+                if (log)
+                    log->Printf("Platform::%s() StructuredDataPlugin launch "
+                                "filter failed.", __FUNCTION__);
+                return process_sp;
+            }
+        }
+    }
+
     error = LaunchProcess (launch_info);
     if (error.Success())
     {
         if (log)
             log->Printf ("Platform::%s LaunchProcess() call succeeded (pid=%" PRIu64 ")", __FUNCTION__, launch_info.GetProcessID ());
         if (launch_info.GetProcessID() != LLDB_INVALID_PROCESS_ID)
         {
             ProcessAttachInfo attach_info (launch_info);