Added enforce-interactivity setting

[labath]

Summary

We are planning on using pipes with LLDB for input and output and need a way to give them access to input/output functions of LLDB even though they are not strictly interactive. This proposed change would add in a setting that would let us accomplish this. If the setting enable_interactivity is set to false, the session will proceed as if it were interactive even if it isn't by definition. By default this setting will be true, thus preserving our existing logic for checking interactivity.

[• joshimbriani]

removed an extra comment and line

[labath]

I would implement this logic slightly differently: Have a ternary setting, let's call it debugger.interactive, whose values are never, always, auto, with auto (the current behavior) being the default. I think that makes it the behavior of the debugger more predictible and understandable, and it is the pattern used in other places as well (see grep --color=WHEN)

That said, I am slightly worried about the idea of controlling the debugger over stdio. I don't know what's your use case, but if you want to make a robust solution, I'd recommend going with scripting API. If there is something you cannot achieve using the scripting API, we'd welcome patches to add the functionality.

[clayborg]

Can you explain the scenarios where you are going to use LLDB with pipes?

[• joshimbriani]

In D23290#511275, @clayborg wrote:

Can you explain the scenarios where you are going to use LLDB with pipes?

Sure! Essentially we are duplicating some of the functionality of the command line, specifically when commands need confirmation (like process handle or breakpoint delete). We are interacting with LLDB to confirm these commands via pipes. And since pipes aren't inherently interactive, we need a way to override the interactivity check so that LLDB will give us the output we want, regardless of whether we are using pipes or not.

[clayborg]

In D23290#511433, @joshimbriani wrote:

In D23290#511275, @clayborg wrote:

Can you explain the scenarios where you are going to use LLDB with pipes?

Sure! Essentially we are duplicating some of the functionality of the command line, specifically when commands need confirmation (like process handle or breakpoint delete). We are interacting with LLDB to confirm these commands via pipes. And since pipes aren't inherently interactive, we need a way to override the interactivity check so that LLDB will give us the output we want, regardless of whether we are using pipes or not.

I think we all got that part. The question is why are you interacting via text input/output and not using the C++ API?

[• joshimbriani]

In D23290#511446, @clayborg wrote:

I think we all got that part. The question is why are you interacting via text input/output and not using the C++ API?

Well we are using the C++ API to initiate the command but the command waits for input from stdin until it is confirmed and since we can't use stdin we're using pipes as the input handler to pass in the input we need to confirm the command and get back the result from the C++ API.

[clayborg]

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???

[labath]

I think I have understood the situation a bit more now, so let me try to explain what is going on.

In 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)

[clayborg]

In 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 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.

[clayborg]

I am not sure this is the right fix. This fix would mean that any IOHandler would always be interactive even if the user didn't want it to be. A better fix would be to make a way to enable interactivity for only certain files.

[labath]

This has been abandoned some time ago.

include/lldb/Core/Debugger.h

public:
     
     uint32_t
     GetTabSize () const;
     
     bool
     SetTabSize (uint32_t tab_size);
 
     bool
+    GetEnforceInteractivity () const;
+
+    bool
+    SetEnforceInteractivity (bool b);
+
+    bool
     GetEscapeNonPrintables () const;
     
     bool
     GetNotifyVoid () const;
     
     const ConstString &
     GetInstanceName()
     {

source/Core/Debugger.cpp

 {   "thread-format",            OptionValue::eTypeFormatEntity, true, 0    , DEFAULT_THREAD_FORMAT, nullptr, "The default thread format string to use when displaying thread information." },
 {   "use-external-editor",      OptionValue::eTypeBoolean     , true, false, nullptr, nullptr, "Whether to use an external editor or not." },
 {   "use-color",                OptionValue::eTypeBoolean     , true, true , nullptr, nullptr, "Whether to use Ansi color codes or not." },
 {   "auto-one-line-summaries",  OptionValue::eTypeBoolean     , true, true, nullptr, nullptr, "If true, LLDB will automatically display small structs in one-liner format (default: true)." },
 {   "auto-indent",              OptionValue::eTypeBoolean     , true, true , nullptr, nullptr, "If true, LLDB will auto indent/outdent code. Currently only supported in the REPL (default: true)." },
 {   "print-decls",              OptionValue::eTypeBoolean     , true, true , nullptr, nullptr, "If true, LLDB will print the values of variables declared in an expression. Currently only supported in the REPL (default: true)." },
 {   "tab-size",                 OptionValue::eTypeUInt64      , true, 4    , nullptr, nullptr, "The tab size to use when indenting code in multi-line input mode (default: 4)." },
 {   "escape-non-printables",    OptionValue::eTypeBoolean     , true, true, nullptr, nullptr, "If true, LLDB will automatically escape non-printable and escape characters when formatting strings." },
+{   "enforce-interactivity",    OptionValue::eTypeBoolean     , true, true, nullptr, nullptr, "If true, LLDB will enforce interactivity checks before executing potentially interactive actions."},
 {   nullptr,                       OptionValue::eTypeInvalid     , true, 0    , nullptr, nullptr, nullptr }
 };
 
 enum
 {
     ePropertyAutoConfirm = 0,
     ePropertyDisassemblyFormat,
     ePropertyFrameFormat,
     ePropertyNotiftVoid,
     ePropertyPrompt,
     ePropertyScriptLanguage,
     ePropertyStopDisassemblyCount,
     ePropertyStopDisassemblyDisplay,
     ePropertyStopLineCountAfter,
     ePropertyStopLineCountBefore,
     ePropertyTerminalWidth,
     ePropertyThreadFormat,
     ePropertyUseExternalEditor,
     ePropertyUseColor,
     ePropertyAutoOneLineSummaries,
     ePropertyAutoIndent,
     ePropertyPrintDecls,
     ePropertyTabSize,
-    ePropertyEscapeNonPrintables
+    ePropertyEscapeNonPrintables,
+    ePropertyEnforceInteractivity
 };
 
 LoadPluginCallbackType Debugger::g_load_plugin_callback = nullptr;
 
 Error
 Debugger::SetPropertyValue (const ExecutionContext *exe_ctx,
                             VarSetOperationType op,
                             const char *property_path,

 
 bool
 Debugger::SetTabSize (uint32_t tab_size)
 {
     const uint32_t idx = ePropertyTabSize;
     return m_collection_sp->SetPropertyAtIndexAsUInt64(nullptr, idx, tab_size);
 }
 
+bool
+Debugger::GetEnforceInteractivity () const
+{
+    const uint32_t idx = ePropertyEnforceInteractivity;
+    return m_collection_sp->GetPropertyAtIndexAsBoolean(nullptr, idx, g_properties[idx].default_uint_value != 0);
+}
+
+bool
+Debugger::SetEnforceInteractivity (bool b)
+{
+    const uint32_t idx = ePropertyEnforceInteractivity;
+    return m_collection_sp->SetPropertyAtIndexAsBoolean(nullptr, idx, b);
+}
+
 #pragma mark Debugger
 
 //const DebuggerPropertiesSP &
 //Debugger::GetSettings() const
 //{
 //    return m_properties_sp;
 //}
 //

source/Core/IOHandler.cpp

#ifndef LLDB_DISABLE_LIBEDIT
     else
     {
 #endif
         line.clear();
 
         FILE *in = GetInputFILE();
         if (in)
         {
-            if (GetIsInteractive())
+            if (GetIsInteractive() || !m_debugger.GetEnforceInteractivity())
             {
                 const char *prompt = nullptr;
                 
                 if (m_multi_line && m_curr_line_idx > 0)
                     prompt = GetContinuationPrompt();
                 
                 if (prompt == nullptr)
                     prompt = GetPrompt();