[Lldb-commits] [PATCH] D23290: Added enforce-interactivity setting

[Greg Clayton via lldb-commits]

clayborg added a comment.

In https://reviews.llvm.org/D23290#512346, @labath wrote:

> I think I have understood the situation a bit more now, so let me try to explain what is going on.
>
> In https://reviews.llvm.org/D23290#511683, @clayborg wrote:
>
> > Is this something the user is typing in your IDE that you are forwarding to LLDB via pipes? Again, why are you using the command and not the API. There are API for everything you can do and no IDE should be doing code like:
> >
> > void MyDebugger::ClearAllBreakpoints()
> >  {
> >
> >   m_debugger.HandleCommand("breakpoint delete");
> >
> > }
> >
> > Can you explain your use case here? If this is something the user is typing, then user PTY instead of pipes and all will be well. I know many functions in the lldb-mi are incorrectly implemented and they actually create and send LLDB commands using text and we need to fix this, so hopefully you aren't copying that code as a basis???
>
>
> Yes, this is for commands that the user is typing by hand into the IDE, which has a tiny lldb console. All commands that are issued by IDE directly use the proper SB APIs. (The IDE is android studio BTW.)
>
> I had also considered using PTYs, but as far as I can tell there is no equivalent of that on windows. (@zturner, do you have any more insight into that? Is it possible to fake a terminal on windows à la POSIX pseudo terminals?).
>
> Greg, how does xcode achieve this? (I presume it has some form of an lldb console)


We use PTY (pseudo terminals). Look at source/Utilitiy/PseudoTerminal.cpp as a wrapper around what you need to do. Basically it goes like this: with pseudo terminals you have master and slave sides. You open the master, and if LLDB is a framework that is in process, you open the slave as well. You take the file descriptor for the slave and you fdopen() it to get a "FILE *" and you give that to your SBDebugger via:

  void SBDebugger::SetInputFileHandle (FILE *f, bool transfer_ownership);
  void SBDebugger::SetOutputFileHandle (FILE *f, bool transfer_ownership);
  void SBDebugger::SetErrorFileHandle (FILE *f, bool transfer_ownership);

One thing to note: if Android Studio can have multiple debugging session windows open, you should have a different SBDebugger each window since each SBDebugger has it's own command interpreter and can set its input/output/error file handles correctly. See the EditlineAdapter::EditlineAdapter() class for details on how to open the master and slave.


https://reviews.llvm.org/D23290