I've updated the patch with your suggestions @jingham

• Renamed SBDebugger::GetAvailablePlatformAtIndex() to GetAvailablePlatformInfoAtIndex().
• Changed PlatformPythonTestCase.test_platform_list to select one of the available platforms instead of hardcoding the remote-linux platform.

Thanks for the review Jim, but I only see the testing suggestion, could you elaborate on the other two issues?

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

Add docstrings to SWIG bindings.

@ki.stfu Are you OK with this going in?

Thanks for the review. AddSlashes is still used in a couple of places (but not for escaping MI output), so I'll leave it be for now.

Rename kUnresolvedValue back to kUknownValue.

Renamed placeholder c-strings.

In D25486#567722, @zturner wrote:

Heh. It just occurred to me that this is probably the reason why all of the lldb-mi tests fail on Windows. Because .exe is not appended. I'm not ready to turn that on and deal with all the failures just yet, but for now can you please add a #TODO right above this that says "Append .exe on Windows"

@zturner Are you good with this going in?

It seems like it should be possible to conditionally enable this using CMAKE_VERSION. However that just means anyone who's silly enough to use an older CMake version may run into the issue this patch attempts to address, so arguably the proper fix is to bump up the CMake version requirement instead. Should probably run this by lldb-dev first.

I believe LLVM requires CMake 2.8.12 or later (at least that was the case
when I looked three weeks ago).

I've looked at the path separator issue you've mentioned earlier in D13201, and I think it's fine as is. All those paths with the forward slashes end up in a FileSpec, which converts forward slashes to backward slashes before passing them through to any Win32 APIs, and FileSpec::GetPath() also converts slashes by default.

Hi Zach,

Added a couple of unit tests, the Windows-specific cleanups will be submitted in a separate patch.

That looks fine to me. CMake prints those messages during the configuration step, at that point the generator expressions haven't been expanded yet. I could prettify those messages a bit to read: Found PythonLibs: C:/Python27_LLDB/x86/libs/python27_d.lib and C:/Python27_LLDB/x86/libs/python27.lib.

Added an explanation of the generator expression used in this patch.

I'll submit a revised patch that contains an explanation of the generator expressions to aid future maintainers/contributors.

I've updated the summary with the scenario. I don't know how one would go about writing a test for this, mixed platform remote debugging is a bit finicky.

According to the GDB-MI spec the exec-run 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 command. So, what's the rationale for diverging from the spec in this case?

Removed the line requested, added a full description of the command to MIExtensions.txt.