remove FILE* usage from ReportEventState() and HandleProcessEvent()

[lawrence_danna]

Summary

This patch adds FileSP and SBFile versions of the API methods
ReportEventState and HandleProcessEvent. It points the SWIG
wrappers at these instead of the ones that use FILE* streams.

[lawrence_danna]

oops, remove unnecessary FileSP reference from interface file

[labath]

Adding Jim for the API design aspects.

Two things come to mind here:

• It's unfortunate that we have to add the FileSP overload (and the associated cruft) to every API that used to take a FILE*. I take it that is needed to get rid of the swig typemaps? Is there any way to avoid it?
• shouldn't these APIs be taking an (SB)Stream instead? I am not sure if we have ever specified the difference between (SB)Stream and (SB)File, but if I had to spell that out, I'd say that this it is that a (SB)Stream supports write-only append-only output, while an (SB)File offers a richer set of APIs (combining reads and writes, random access, etc.). In this sense, it looks like both of these APIs should be perfectly fine (now and for the forseeable future) with a (SB)Stream. Should we make a new overload taking a SBStream instead? Jim, do you know why these functions are taking a FILE*. Could it be that they predate SBStream?

[jingham]

SBProcess::ReportEventState was introduced in r112221, and SBStream was added in r114188, so Pavel's speculation seems like a reasonable one, though that was 9 years ago...

But in the SB API's we use SBStream in a bunch of places to be more like an SBString, something you can pass to a client and they will add some data to it, and then you call GetData to get the result. That's a not very stream-like usage.

In the case of HandleProcessEvent, SBDebugger uses it for HandleCommand, when it wants to dump all the stop event data to the Debugger's STDIO. That would be less convenient with an SBStream, you'd have to make one, then Redirect it to the debugger's stdout & stderr. That seems kind of awkward.

[lawrence_danna]

In D68546#1697302, @labath wrote:

Adding Jim for the API design aspects.

It's unfortunate that we have to add the FileSP overload (and the associated cruft) to every API that used to take a FILE*. I take it that is needed to get rid of the swig typemaps? Is there any way to avoid it?

I think at the swig level there really does need to be two, because they're doing two different things. The FileSP version takes a python file object and converts it, and then passes it in. This should have the same behavior as the old FILE* binding. The SBFile takes a file that has already been converted -- possibly with the borrow or force_io_methods flags set, and passes that in directly, without doing further conversion.

I could take the duplicates out of the .h and .cpp files, and use %extend to add them back in in the .i files. Is that cleaner?

[lawrence_danna]

Personally, I think %extend is a bit ugly as it increases the difference between what's in the headers and what's actually in the python bindings, so I'd rather not do it that way. But I'm not dogmatically opposed to it.

[labath]

Thanks for weighing in, Jim. My responses are inline.

In D68546#1698430, @jingham wrote:

SBProcess::ReportEventState was introduced in r112221, and SBStream was added in r114188, so Pavel's speculation seems like a reasonable one, though that was 9 years ago...

But in the SB API's we use SBStream in a bunch of places to be more like an SBString, something you can pass to a client and they will add some data to it, and then you call GetData to get the result. That's a not very stream-like usage.

Why not? I think that's fairly similar to how one uses std::ostringstream.

std::ostringstream stream;
write_some_data_to(stream); // or stream << stuff;
std::string data = stream.str();

I think the main non-stream like feature of SBStream is that it behaves like std::ostringstream _by default_, but then it can be later converted to something like std::ofstream by calling RedirectToFile. However, I think that is something that can still be fixed, mostly..

In the case of HandleProcessEvent, SBDebugger uses it for HandleCommand, when it wants to dump all the stop event data to the Debugger's STDIO. That would be less convenient with an SBStream, you'd have to make one, then Redirect it to the debugger's stdout & stderr. That seems kind of awkward.

So, what would you say if we added a SBStream constructor taking an SBFile (which would do equivalent of SBStream::RedirectToFile). Then all HandleCommand would have to do is call HandleProcessEvent(process, event, SBStream(GetOutputFile()), SBStream(GetErrorFile())). I think that would be fairly familiar to anyone who has worked with stream, as creating a stream which uses some other object (file, fd, string, ...) as a backing store is a pretty common pattern.

lldb/source/API/SBProcess.cpp

359–362

For instance, this code already kind of mocks a "stream wrapping a file object" by using snprintf. If we had a real stream object around (which properly supported formatted IO) then this could be simplified to stream->Printf(...)

[labath]

In D68546#1698622, @lawrence_danna wrote:

Personally, I think %extend is a bit ugly as it increases the difference between what's in the headers and what's actually in the python bindings, so I'd rather not do it that way. But I'm not dogmatically opposed to it.

Yeah, the %extends are somewhat ugly, but I also find the FileSP overloads in the "public" sections of the SB classes unnerving too, because they are not really public -- no user can actually call them directly in a meaningful way. They are really only meant for the python interface, which sort does sit on the other side of the SB api, but also kind of doesn't. That's the weird part about lldb python support, where python can be embedded *into* lldb, but it also can be sitting *above* it (or both at the same time). I am not really sure what to do about that. I don't suppose there's any way to make the FileSP overloads private?

Or maybe they actually should be public, and the actual problem is that there is no way for a c++ user to make use of this functionality, even though it should be able to? Right now, the c++ api is sort of disadvantaged in that one cannot create an SBFile that would redirect to some custom fancy c++ output object. I am not saying you should implement that, but if we assume that such functionality were available do you think it would be possible to implement the python stuff on top of that? In that sense, maybe the FileSP overloads are actually fine, and we can treat them as a placeholder for this hypothetical future functionality?

I am sorry if this doesn't make much sense -- that's because I myself am not clear on this matter. But I hope that I at least managed to give you an idea of the things going through my head right now. If you have any thoughts on any of this, I'd like to hear them.

[jingham]

In D68546#1699390, @labath wrote:

Thanks for weighing in, Jim. My responses are inline.

In D68546#1698430, @jingham wrote:

SBProcess::ReportEventState was introduced in r112221, and SBStream was added in r114188, so Pavel's speculation seems like a reasonable one, though that was 9 years ago...

But in the SB API's we use SBStream in a bunch of places to be more like an SBString, something you can pass to a client and they will add some data to it, and then you call GetData to get the result. That's a not very stream-like usage.

Why not? I think that's fairly similar to how one uses std::ostringstream.

std::ostringstream stream;
write_some_data_to(stream); // or stream << stuff;
std::string data = stream.str();

I think the main non-stream like feature of SBStream is that it behaves like std::ostringstream _by default_, but then it can be later converted to something like std::ofstream by calling RedirectToFile. However, I think that is something that can still be fixed, mostly..

In most of the uses of SBStream (and all the ones' I've done for the various scripts I've written), I would be very surprised if GetData returned nothing because the data had gone elsewhere. I find myself always wanting that output. That's what I meant by saying it was more string-like that stream-like. But that behavior is really at the boundary between lldb & scripts, and can be controlled by the person providing the stream. It is a little weird however that this behavior is non-explicit in SBStream. W.R.T. below, I wonder if it wouldn't have been better to make the Stream output -> File behavior be something that has to be set at construction time and not modifiable. It would be really surprising if I made an SBStream to gather a Description, and have somebody under the covers decide to drain the output off to a file.

In the case of HandleProcessEvent, SBDebugger uses it for HandleCommand, when it wants to dump all the stop event data to the Debugger's STDIO. That would be less convenient with an SBStream, you'd have to make one, then Redirect it to the debugger's stdout & stderr. That seems kind of awkward.

So, what would you say if we added a SBStream constructor taking an SBFile (which would do equivalent of SBStream::RedirectToFile). Then all HandleCommand would have to do is call HandleProcessEvent(process, event, SBStream(GetOutputFile()), SBStream(GetErrorFile())). I think that would be fairly familiar to anyone who has worked with stream, as creating a stream which uses some other object (file, fd, string, ...) as a backing store is a pretty common pattern.

This would be fine.

[lawrence_danna]

In D68546#1699397, @labath wrote:

Yeah, the %extends are somewhat ugly, but I also find the FileSP overloads in the "public" sections of the SB classes unnerving too, because they are not really public -- no user can actually call them directly in a meaningful way. They are really only meant for the python interface, which sort does sit on the other side of the SB api, but also kind of doesn't. That's the weird part about lldb python support, where python can be embedded *into* lldb, but it also can be sitting *above* it (or both at the same time). I am not really sure what to do about that. I don't suppose there's any way to make the FileSP overloads private?

I don't think so, because the SWIG wrappers need to see them. They are de-facto private though, because they require an argument of type std::shared_ptr<lldb_private::File>.
All external API clients can see is a forward declaration that lldb_private::File is a class. They can make a NULL pointer to one, but that's it.

Or maybe they actually should be public, and the actual problem is that there is no way for a c++ user to make use of this functionality, even though it should be able to? Right now, the c++ api is sort of disadvantaged in that one cannot create an SBFile that would redirect to some custom fancy c++ output object. I am not saying you should implement that, but if we assume that such functionality were available do you think it would be possible to implement the python stuff on top of that? In that sense, maybe the FileSP overloads are actually fine, and we can treat them as a placeholder for this hypothetical future functionality?

I am sorry if this doesn't make much sense -- that's because I myself am not clear on this matter. But I hope that I at least managed to give you an idea of the things going through my head right now. If you have any thoughts on any of this, I'd like to hear them.

No, it does make sense. I too thought it was kind of odd that there's a python API which is inaccessible from C++. I can't really think of any ultimate use case where a C++ binding for File I/O callbacks would be needed, but if it were, I can think of three ways to do it.

The first and simplest way to support it is to just use funopen() or whatever the equivalent of that is on your platform to make a FILE*. I put the FILE* constructor in for C++ even though it will never have a SWIG wrapper so this would be possible. The disadvantage is that funopen() isn't portable, so clients that go this route will need platform specific code to do it.

The intermediate method would be to make our own funopen that would act as a factory function for FileSP. File would remain private, but you could make one with callbacks if you wanted to. Disadvantage here is that C++ clients would be calling though a chain of two function pointers to actually get to the Read and Write methods. This is still better from a performance perspective than calling into a Python method, but if we wanted to avoid that, we could go one step further.

The most complicated way we could handle it would be to expose an ABI-stable abstract base class of File in the API headers. This should be at the base of the File class hierarchy, where IOObject is now. It would only have virtual methods, and it would also have a bunch of unused dummy virtual so we can add new virtual methods later if we need too, without changing the ABI. C++ clients could then just subclass their own File types and use FileSP directly. I think to do this properly we'd need to do some more refactoring, because I'm not sure what should happen to IOObject and Socket under this scenario, or what kinds of error codes the virtual methods should be returning.

[lawrence_danna]

So what's the conclusion here? Should HandleProcessEvent get a SBStream variant as well? I say "as well", because the FileSP variant is required in order to remove the python binding to the FILE* variant, and once we have the FileSP it seems like it would be really strange to leave out the SBFile.

[lawrence_danna]

rebased

[labath]

In D68546#1700273, @lawrence_danna wrote:

So what's the conclusion here? Should HandleProcessEvent get a SBStream variant as well? I say "as well", because the FileSP variant is required in order to remove the python binding to the FILE* variant, and once we have the FileSP it seems like it would be really strange to leave out the SBFile.

Well... if we agree that SBStream is the future for APIs like this, then I don't think that would be too strange. The FileSP and FILE* variants would both be "legacy/deprecated" and present only to support legacy c++/python uses, and the SBStream would be the thing which we expect new users to use.

That said, I don't think that having an SBFile-based API is that bad either (though I would still like if it is used via an SBStream internally).. The main advantage of the "higher level" stream interface I see is that it is easier to provide your own implementation of it (less methods to override). However, given that we've just went through the exercise of making the file API overridable externally, I don't think we'll want to create an overridable stream abstraction any time soon.

[lawrence_danna]

In D68546#1705684, @labath wrote:

Well... if we agree that SBStream is the future for APIs like this, then I don't think that would be too strange. The FileSP and FILE* variants would both be "legacy/deprecated" and present only to support legacy c++/python uses, and the SBStream would be the thing which we expect new users to use.

That said, I don't think that having an SBFile-based API is that bad either (though I would still like if it is used via an SBStream internally).. The main advantage of the "higher level" stream interface I see is that it is easier to provide your own implementation of it (less methods to override). However, given that we've just went through the exercise of making the file API overridable externally, I don't think we'll want to create an overridable stream abstraction any time soon.

Ok I'll just update it to go though StreamFile internally and leave the decision of whether a SBStream version should be added to a later patch and/or someone else to decide.

[lawrence_danna]

use stream

[lawrence_danna]

swig 3 fix

[labath]

In D68546#1706424, @lawrence_danna wrote:

Ok I'll just update it to go though StreamFile internally and leave the decision of whether a SBStream version should be added to a later patch and/or someone else to decide.

SGTM

lldb/include/lldb/API/SBDebugger.h

public:
 
   lldb::SBCommandInterpreter GetCommandInterpreter();
 
   void HandleCommand(const char *command);
 
   lldb::SBListener GetListener();
 
   void HandleProcessEvent(const lldb::SBProcess &process,
-                          const lldb::SBEvent &event, FILE *out, FILE *err);
+                          const lldb::SBEvent &event, FILE *out,
+                          FILE *err); // DEPRECATED
+
+  void HandleProcessEvent(const lldb::SBProcess &process,
+                          const lldb::SBEvent &event, SBFile out, SBFile err);
+
+  void HandleProcessEvent(const lldb::SBProcess &process,
+                          const lldb::SBEvent &event, FileSP out, FileSP err);
 
   lldb::SBTarget CreateTarget(const char *filename, const char *target_triple,
                               const char *platform_name,
                               bool add_dependent_modules, lldb::SBError &error);
 
   lldb::SBTarget CreateTargetWithFileAndTargetTriple(const char *filename,
                                                      const char *target_triple);
 

lldb/include/lldb/API/SBFile.h

 
 #include "lldb/API/SBDefines.h"
 
 namespace lldb {
 
 class LLDB_API SBFile {
   friend class SBDebugger;
   friend class SBCommandReturnObject;
+  friend class SBProcess;
 
 public:
   SBFile();
   SBFile(FileSP file_sp);
   SBFile(FILE *file, bool transfer_ownership);
   SBFile(int fd, const char *mode, bool transfer_ownership);
   ~SBFile();
 

lldb/include/lldb/API/SBProcess.h

public:
   size_t GetSTDOUT(char *dst, size_t dst_len) const;
 
   size_t GetSTDERR(char *dst, size_t dst_len) const;
 
   size_t GetAsyncProfileData(char *dst, size_t dst_len) const;
 
   void ReportEventState(const lldb::SBEvent &event, FILE *out) const;
 
+  void ReportEventState(const lldb::SBEvent &event, SBFile file) const;
+
+  void ReportEventState(const lldb::SBEvent &event, FileSP file) const;
+
   void AppendEventStateReport(const lldb::SBEvent &event,
                               lldb::SBCommandReturnObject &result);
 
   /// Remote connection related functions. These will fail if the
   /// process is not in eStateConnected. They are intended for use
   /// when connecting to an externally managed debugserver instance.
   bool RemoteAttachToProcessWithID(lldb::pid_t pid, lldb::SBError &error);
 

lldb/packages/Python/lldbsuite/test/python_api/default-constructor/sb_debugger.py

def fuzz_obj(obj):
     obj.SetOutputFileHandle(None, True)
     obj.SetErrorFileHandle(None, True)
     obj.GetInputFileHandle()
     obj.GetOutputFileHandle()
     obj.GetErrorFileHandle()
     obj.GetCommandInterpreter()
     obj.HandleCommand("nothing here")
     listener = obj.GetListener()
+    try:
         obj.HandleProcessEvent(lldb.SBProcess(), lldb.SBEvent(), None, None)
+    except Exception:
+        pass
     obj.CreateTargetWithFileAndTargetTriple("a.out", "A-B-C")
     obj.CreateTargetWithFileAndArch("b.out", "arm")
     obj.CreateTarget("c.out")
     obj.DeleteTarget(lldb.SBTarget())
     obj.GetTargetAtIndex(0xffffffff)
     obj.FindTargetWithProcessID(0)
     obj.FindTargetWithFileAndArch("a.out", "arm")
     obj.GetNumTargets()

lldb/packages/Python/lldbsuite/test/python_api/default-constructor/sb_process.py

 """
 Fuzz tests an object after the default construction to make sure it does not crash lldb.
 """
 
 import lldb
 
 
 def fuzz_obj(obj):
     obj.GetTarget()
     obj.GetByteOrder()
     obj.PutSTDIN("my data")
     obj.GetSTDOUT(6)
     obj.GetSTDERR(6)
     event = lldb.SBEvent()
+    try:
         obj.ReportEventState(event, None)
+    except Exception:
+        pass
     obj.AppendEventStateReport(event, lldb.SBCommandReturnObject())
     error = lldb.SBError()
     obj.RemoteAttachToProcessWithID(123, error)
     obj.RemoteLaunch(None, None, None, None, None, None, 0, False, error)
     obj.GetNumThreads()
     obj.GetThreadAtIndex(0)
     obj.GetThreadByID(0)
     obj.GetSelectedThread()

lldb/scripts/interface/SBDebugger.i

public:
     HandleCommand (const char *command);
 
     lldb::SBListener
     GetListener ();
 
     void
     HandleProcessEvent (const lldb::SBProcess &process,
                         const lldb::SBEvent &event,
-                        FILE *out,
-                        FILE *err);
+                        SBFile out,
+                        SBFile err);
+
+    void
+    HandleProcessEvent (const lldb::SBProcess &process,
+                        const lldb::SBEvent &event,
+                        FileSP BORROWED,
+                        FileSP BORROWED);
 
     lldb::SBTarget
     CreateTarget (const char *filename,
                   const char *target_triple,
                   const char *platform_name,
                   bool add_dependent_modules,
                   lldb::SBError& sb_error);
 

lldb/scripts/interface/SBProcess.i

public:
     Python string.") GetSTDERR;
     size_t
     GetSTDERR (char *dst, size_t dst_len) const;
 
     size_t
     GetAsyncProfileData(char *dst, size_t dst_len) const;
 
     void
-    ReportEventState (const lldb::SBEvent &event, FILE *out) const;
+    ReportEventState (const lldb::SBEvent &event, SBFile out) const;
+
+    void
+    ReportEventState (const lldb::SBEvent &event, FileSP BORROWED) const;
 
     void
     AppendEventStateReport (const lldb::SBEvent &event, lldb::SBCommandReturnObject &result);
 
     %feature("docstring", "
     Remote connection related functions. These will fail if the
     process is not in eStateConnected. They are intended for use
     when connecting to an externally managed debugserver instance.") RemoteAttachToProcessWithID;

lldb/source/API/SBDebugger.cpp

if (!m_opaque_sp->GetAsyncExecution()) {
       SBProcess process(GetCommandInterpreter().GetProcess());
       ProcessSP process_sp(process.GetSP());
       if (process_sp) {
         EventSP event_sp;
         ListenerSP lldb_listener_sp = m_opaque_sp->GetListener();
         while (lldb_listener_sp->GetEventForBroadcaster(
             process_sp.get(), event_sp, std::chrono::seconds(0))) {
           SBEvent event(event_sp);
-          HandleProcessEvent(process, event, GetOutputFileHandle(),
-                             GetErrorFileHandle());
+          HandleProcessEvent(process, event, GetOutputFile(), GetErrorFile());
         }
       }
     }
   }
 }
 
 SBListener SBDebugger::GetListener() {
   LLDB_RECORD_METHOD_NO_ARGS(lldb::SBListener, SBDebugger, GetListener);
 
   SBListener sb_listener;
   if (m_opaque_sp)
     sb_listener.reset(m_opaque_sp->GetListener());
 
   return LLDB_RECORD_RESULT(sb_listener);
 }
 
 void SBDebugger::HandleProcessEvent(const SBProcess &process,
+                                    const SBEvent &event, SBFile out,
+                                    SBFile err) {
+  LLDB_RECORD_METHOD(
+      void, SBDebugger, HandleProcessEvent,
+      (const lldb::SBProcess &, const lldb::SBEvent &, SBFile, SBFile), process,
+      event, out, err);
+
+  return HandleProcessEvent(process, event, out.m_opaque_sp, err.m_opaque_sp);
+}
+
+void SBDebugger::HandleProcessEvent(const SBProcess &process,
                                     const SBEvent &event, FILE *out,
                                     FILE *err) {
   LLDB_RECORD_METHOD(
       void, SBDebugger, HandleProcessEvent,
       (const lldb::SBProcess &, const lldb::SBEvent &, FILE *, FILE *), process,
       event, out, err);
 
+  FileSP outfile = std::make_shared<NativeFile>(out, false);
+  FileSP errfile = std::make_shared<NativeFile>(err, false);
+  return HandleProcessEvent(process, event, outfile, errfile);
+}
+
+void SBDebugger::HandleProcessEvent(const SBProcess &process,
+                                    const SBEvent &event, FileSP out_sp,
+                                    FileSP err_sp) {
+
+  LLDB_RECORD_METHOD(
+      void, SBDebugger, HandleProcessEvent,
+      (const lldb::SBProcess &, const lldb::SBEvent &, FileSP, FileSP), process,
+      event, out_sp, err_sp);
+
   if (!process.IsValid())
     return;
 
   TargetSP target_sp(process.GetTarget().GetSP());
   if (!target_sp)
     return;
 
   const uint32_t event_type = event.GetType();
   char stdio_buffer[1024];
   size_t len;
 
   std::lock_guard<std::recursive_mutex> guard(target_sp->GetAPIMutex());
 
   if (event_type &
       (Process::eBroadcastBitSTDOUT | Process::eBroadcastBitStateChanged)) {
     // Drain stdout when we stop just in case we have any bytes
     while ((len = process.GetSTDOUT(stdio_buffer, sizeof(stdio_buffer))) > 0)
-      if (out != nullptr)
-        ::fwrite(stdio_buffer, 1, len, out);
+      if (out_sp)
+        out_sp->Write(stdio_buffer, len);
   }
 
   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 (err_sp)
+        err_sp->Write(stdio_buffer, len);
   }
 
   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);
+      process.ReportEventState(event, out_sp);
   }
 }
 
 SBSourceManager SBDebugger::GetSourceManager() {
   LLDB_RECORD_METHOD_NO_ARGS(lldb::SBSourceManager, SBDebugger,
                              GetSourceManager);
 
   SBSourceManager sb_source_manager(*this);
template <> void RegisterMethods<SBDebugger>(Registry &R) {
   LLDB_REGISTER_METHOD(void, SBDebugger, RestoreInputTerminalState, ());
   LLDB_REGISTER_METHOD(lldb::SBCommandInterpreter, SBDebugger,
                        GetCommandInterpreter, ());
   LLDB_REGISTER_METHOD(void, SBDebugger, HandleCommand, (const char *));
   LLDB_REGISTER_METHOD(lldb::SBListener, SBDebugger, GetListener, ());
   LLDB_REGISTER_METHOD(
       void, SBDebugger, HandleProcessEvent,
       (const lldb::SBProcess &, const lldb::SBEvent &, FILE *, FILE *));
+  LLDB_REGISTER_METHOD(
+      void, SBDebugger, HandleProcessEvent,
+      (const lldb::SBProcess &, const lldb::SBEvent &, SBFile, SBFile));
+  LLDB_REGISTER_METHOD(
+      void, SBDebugger, HandleProcessEvent,
+      (const lldb::SBProcess &, const lldb::SBEvent &, FileSP, FileSP));
   LLDB_REGISTER_METHOD(lldb::SBSourceManager, SBDebugger, GetSourceManager, ());
   LLDB_REGISTER_STATIC_METHOD(bool, SBDebugger, SetDefaultArchitecture,
                               (const char *));
   LLDB_REGISTER_METHOD(lldb::ScriptLanguage, SBDebugger, GetScriptingLanguage,
                        (const char *));
   LLDB_REGISTER_STATIC_METHOD(const char *, SBDebugger, GetVersionString, ());
   LLDB_REGISTER_STATIC_METHOD(const char *, SBDebugger, StateAsCString,
                               (lldb::StateType));

lldb/source/API/SBProcess.cpp

 #include "lldb/Target/SystemRuntime.h"
 #include "lldb/Target/Target.h"
 #include "lldb/Target/Thread.h"
 #include "lldb/Utility/Args.h"
 #include "lldb/Utility/ProcessInfo.h"
 #include "lldb/Utility/State.h"
 #include "lldb/Utility/Stream.h"
 
-
 #include "lldb/API/SBBroadcaster.h"
 #include "lldb/API/SBCommandReturnObject.h"
 #include "lldb/API/SBDebugger.h"
 #include "lldb/API/SBEvent.h"
+#include "lldb/API/SBFile.h"
 #include "lldb/API/SBFileSpec.h"
 #include "lldb/API/SBMemoryRegionInfo.h"
 #include "lldb/API/SBMemoryRegionInfoList.h"
 #include "lldb/API/SBStream.h"
 #include "lldb/API/SBStringList.h"
 #include "lldb/API/SBStructuredData.h"
 #include "lldb/API/SBThread.h"
 #include "lldb/API/SBThreadCollection.h"
if (!process_sp) {
     error.SetErrorString("invalid process");
   } else {
     uid = process_sp->StartTrace(*(options.m_traceoptions_sp), error.ref());
     trace_instance.SetTraceUID(uid);
   }
   return LLDB_RECORD_RESULT(trace_instance);
 }
 
+void SBProcess::ReportEventState(const SBEvent &event, SBFile out) const {
+  LLDB_RECORD_METHOD_CONST(void, SBProcess, ReportEventState,
+                           (const SBEvent &, SBFile), event, out);
+
+  return ReportEventState(event, out.m_opaque_sp);
+}
+
 void SBProcess::ReportEventState(const SBEvent &event, FILE *out) const {
   LLDB_RECORD_METHOD_CONST(void, SBProcess, ReportEventState,
                            (const lldb::SBEvent &, FILE *), event, out);
+  FileSP outfile = std::make_shared<NativeFile>(out, false);
+  return ReportEventState(event, outfile);
+}
+
+void SBProcess::ReportEventState(const SBEvent &event, FileSP out) const {
 
-  if (out == nullptr)
+  LLDB_RECORD_METHOD_CONST(void, SBProcess, ReportEventState,
+                           (const SBEvent &, FileSP), event, out);
+
+  if (!out || !out->IsValid())
     return;
 
   ProcessSP process_sp(GetSP());
   if (process_sp) {
+    StreamFile stream(out);
     const StateType event_state = SBProcess::GetStateFromEvent(event);
-    char message[1024];
-    int message_len = ::snprintf(
-        message, sizeof(message), "Process %" PRIu64 " %s\n",
+    stream.Printf("Process %" PRIu64 " %s\n",
         process_sp->GetID(), SBDebugger::StateAsCString(event_state));
-
-    if (message_len > 0)
-      ::fwrite(message, 1, message_len, out);
   }
 }
 
 void SBProcess::AppendEventStateReport(const SBEvent &event,
                                        SBCommandReturnObject &result) {
   LLDB_RECORD_METHOD(void, SBProcess, AppendEventStateReport,
                      (const lldb::SBEvent &, lldb::SBCommandReturnObject &),
                      event, result);
 
void RegisterMethods<SBProcess>(Registry &R) {
   LLDB_REGISTER_METHOD_CONST(size_t, SBProcess, GetSTDOUT, (char *, size_t));
   LLDB_REGISTER_METHOD_CONST(size_t, SBProcess, GetSTDERR, (char *, size_t));
   LLDB_REGISTER_METHOD_CONST(size_t, SBProcess, GetAsyncProfileData,
                              (char *, size_t));
   LLDB_REGISTER_METHOD(lldb::SBTrace, SBProcess, StartTrace,
                        (lldb::SBTraceOptions &, lldb::SBError &));
   LLDB_REGISTER_METHOD_CONST(void, SBProcess, ReportEventState,
                              (const lldb::SBEvent &, FILE *));
+  LLDB_REGISTER_METHOD_CONST(void, SBProcess, ReportEventState,
+                             (const lldb::SBEvent &, FileSP));
+  LLDB_REGISTER_METHOD_CONST(void, SBProcess, ReportEventState,
+                             (const lldb::SBEvent &, SBFile));
   LLDB_REGISTER_METHOD(
       void, SBProcess, AppendEventStateReport,
       (const lldb::SBEvent &, lldb::SBCommandReturnObject &));
   LLDB_REGISTER_METHOD(bool, SBProcess, SetSelectedThread,
                        (const lldb::SBThread &));
   LLDB_REGISTER_METHOD(bool, SBProcess, SetSelectedThreadByID, (lldb::tid_t));
   LLDB_REGISTER_METHOD(bool, SBProcess, SetSelectedThreadByIndexID,
                        (uint32_t));