enlight added a subscriber: enlight. enlight added a comment. According to the GDB-MI spec the exec-run <https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Program-Execution.html#GDB_002fMI-Program-Execution> command already has a **start** option. Support for the **start** option can be detected by checking for **exec-run-start-option** in the list of features returned by the list-features <https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Support-Commands.html#GDB_002fMI-Support-Commands> command. So, what's the rationale for diverging from the spec in this case?
In GDB your example would be written as: -exec-run --start ================ Comment at: tools/lldb-mi/MICmdCmdExec.cpp:92 @@ +91,3 @@ + const char *pCmd = bProcessMustStopAtEntry ? "process launch -s" : "process launch"; + const lldb::ReturnStatus rtn = rSessionInfo.GetDebugger().GetCommandInterpreter().HandleCommand(pCmd, m_lldbResult); + MIunused(rtn); ---------------- The process should be launched through the SB API, not the command interpreter. I'm not very familiar with the SB API but I'd try using the **lldb::eLaunchFlagStopAtEntry** flag with **SBLaunchInfo::SetLaunchFlags()**. Repository: rL LLVM http://reviews.llvm.org/D12977 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
