I'd like to make Windows an officially supported platform for LLDB.

The LLDB homepage has the following to say about platform support:

LLDB is known to work on the following platforms, but ports to new platforms are welcome:

  • Mac OS X desktop user space debugging for i386 and x86-64
  • iOS simulator debugging on i386
  • iOS device debugging on ARM
  • Linux local user-space debugging for i386 and x86-64
  • FreeBSD local user-space debugging for i386 and x86-64
    Windows is not listed here. I would like to list it. What level of functionality needs to be present, and how many tests need to pass before I can list Windows here? Can I do it now, with the caveat that it’s still experimental? I have the test suite running (although many tests failing), source level debugging with DWARF, breakpoints, stepping, stack traces, etc all working with basic support, so this seems like a good time to announce support for Windows. Obviously many things will not work, but we plan to support this long term, so it will just be a matter of time.

Along with an update to the supported platforms on the homepage, I plan to add some specific Windows instructions to the build page related to Python, required packages that need to be installed, etc.

Additionally, I hope to follow this up with a post to the LLVM blog announcing experimental support for live debugging on Windows along with a very high level overview of our future plans.

BTW, I actually uploaded a patch to do this. http://reviews.llvm.org/D6805

My big issue with Windows LLDB right now is the python support. I can do most things in the interpreter, but some things just don’t quite work right. For example, using lldb.debugger is spotty:

(lldb) script

Python Interactive Interpreter. To exit, type ‘quit()’, ‘exit()’ or Ctrl-D.

print lldb

<module ‘lldb’ from ‘R:\internal\branch-7.3\windows\latest\Tools\lib\site-packages\lldb_init_.py’>

print lldb.debugger

No value

print lldb.debugger.GetSelectedTarget()

No value

target = lldb.debugger.GetSelectedTarget()

target.BreakpointCreateByName(“main”)

<lldb.SBBreakpoint; proxy of <Swig Object of type ‘lldb::SBBreakpoint *’ at 0x00

00000003EEBBA0> >

quit

(lldb) breakpoint list

No breakpoints currently set.

(lldb) b main

Breakpoint 1: where = factwin`main + 28 at factorial.c:32, address = 0x00005130

(lldb) breakpoint list

Current breakpoints:

1: name = ‘main’, locations = 1

1.1: where = factwin`main + 28 at factorial.c:32, address = factwin[0x00005130], unresolved, hit count = 0

(lldb)

These sequences work on Linux.

If you find Windows specific bugs, can you please file bugs about them and either CC me on them or assign them to me? (Or even better, submit a patch)

For example, I had no way of knowing about that bug until just now when you told me about it. I may have run into eventually as part of the normal course of fixing failing tests, but it’s easier when there’s just already bugs for me to look at.