Is anyone using lldb on Windows to debug a _Windows_ application

Subprojects LLDB
1

Hi,

I tried both building lldb with MSVC and with MinGW both failed to debug native Windows executables (I actually tried 3 types of executables, 1 built with MinGW, 1 with clang 3.4 and 1 with Visual Studio)

This is the error I am getting:

$ lldb D:/src/TestArea/ClangVC/Debug/ClangVC.exe
error: ‘D:/src/TestArea/ClangVC/Debug/ClangVC.exe’ doesn’t contain any ‘host’ platform architectures:
(lldb)

So the question is:

​Is it possible to use lldb on Windows (for local debugging not remote debugging)

2

Hi Eran,

I got the same when I try to debug a _Linux_ application on Linux running on non-PC CPU. Seems like only 'MacOSX and Linux' on 'i686 and x86_64' are properly supported. Problem was already described in the message here: http://comments.gmane.org/gmane.comp.debugging.lldb.devel/3530

I'd love to try and extend lldb support to Linux on AArch64, although cross-compilation comes with its own struggles that I need to deal with first.

I guess woriking out this kind of support for Windows on PC should not be hard.

3

Hi Eran,

I got the same when I try to debug a _Linux_ application on Linux running on non-PC CPU. Seems like only 'MacOSX and Linux' on 'i686 and x86_64' are properly supported. Problem was already described in the message here: http://comments.gmane.org/gmane.comp.debugging.lldb.devel/3530

I'd love to try and extend lldb support to Linux on AArch64, although cross-compilation comes with its own struggles that I need to deal with first.

I guess woriking out this kind of support for Windows on PC should not be hard.

4

Hi Paul,

Seems like only ‘MacOSX and Linux’ on ‘i686 and x86_64’ are properly supported.

For sure the Linux support is really just x86_64 and x86 32-bit to some extent, and not other architectures.

It’s very likely we’ll have AArch64 Linux working at some point. We’re working on bringing LLDB up on Android, and one of the earlier steps is getting lldb-gdbserver (llgs) working on Linux (first x86_64, but later many of the architectures that Android supports).

We’re less focused on local debugging than on debugging through the gdb-remote protocol. However, Greg Clayton and I have talked some about bringing the NativeProcessProtocol and NativeThreadProtocol mechanisms by which llgs is getting implemented to the local debugging side as well (i.e. re-engineering local debugging in terms of Native{Process,Thread}Protocol).

If you’re interested, you can see the latest state of the lldb-gdbserver support here:

https://github.com/tfiala/lldb/tree/dev-tfiala-native-protocol-linux-x86_64

llgs is getting implemented for linux-x86_64 first. Ed Maste is planning on getting it working for FreeBSD, and Greg and the Apple folks plan to move from debugserver over to llgs at some point after we work the kinks out of llgs.

I did spend several days attempting to get an Aarch64 build environment on a DS-5 simulator and a Linaro Aarch64 linux distro but the combination of the lack of speed and the challenges I worked through with some very helpful ARM engineers made this a less productive avenue than my current linux x86_64 bring-up. I plan to return back to that or a similar arm64 environment in the near future.

5

Hi Todd,

Seems like accidently I've started off-topic here. The guy asked about Windows while I'm more into Linux and I brought my issues only due to obvious similarities.

For sure the Linux support is really just x86_64 and x86 32-bit to some

extent, and not other architectures.

It's very likely we'll have AArch64 Linux working at some point. We're

working on bringing LLDB up on Android, and one of the earlier steps is getting lldb-gdbserver (llgs) working on Linux (first x86_64,

but later many of the architectures that Android supports).

For varoius reasons I'm avoiding limiting myself to Android. Even on my PandaBoard I'm running Ubuntu image downloaded from Linaro. I hope llgs will not use anything strictly bionic and/or binder dependand.

We're less focused on local debugging than on debugging through the

gdb-remote protocol. However, Greg Clayton and I have talked some about bringing the NativeProcessProtocol and NativeThreadProtocol

mechanisms by which llgs is getting implemented to the local debugging

side as well (i.e. re-engineering local debugging in terms of Native{Process,Thread}Protocol).

Seems like extending native lldb support to ARM and/or AArch64 is not something individual contributor should or can do and need some discussion with wider agreement of wider board of developers.

6

I hope llgs will not use anything strictly bionic and/or binder dependand.

I’ve been focusing on Ubuntu Linux, initially 12.04 LTS but soon to be focusing more on 14.04 LTS. First x86_64, then other architectures. We’ll also be bringing in Android support. So no, not focusing only on Android (and as part of bring-up, focusing on Ubuntu Linux first).

I expect most of the Android code will be more or less pure Linux. However, there are some areas where some of the changes in Android (e.g. security-related lock-down) may require making Android-specific calls at some point to handle an Android target. We’ll keep those areas cleanly abstracted though as the bulk of the Linux process monitoring should be identical.

Seems like extending native lldb support to ARM and/or AArch64 is not something individual contributor should or can do and need some discussion with wider agreement of wider board of developers.

Feel free to take a shot at it if you’re interested. If you’re interested in local debugging, you can try to modify the existing TOT Linux ProcessMonitor code and the relevant RegisterContext code. If you want to fork the llgs branch, have a look at NativeProcessProtocol/NativeThreadProtocol/NativeRegisterContext. These are implemented for Linux with NativeProcessLinux, NativeThreadLinux and NativeRegisterContextLinux_x86_64. The register context code is the big place that will need some adjustment. There is some register context factory code in NativeThreadLinux that will need some tweaks, and some software breakpoint code that will need to change in NativeProcessLinux.

Otherwise, we’ll be happily getting to it for the llgs side.

7

Hi Eran,

Windows is not supported as a target platform on ToT.

Virgile Bello has a branch on his github account () which does, though. Ive tried it with small gcc-built dwarf2 debug binaries. It works enough to stop at breakpoints, stepping, viewing the stack, etc. You may need to do some merging to trunk, last time I tried the branch was a few months ago. Colin

8

No, we currently don't support native debugging on windows as far as I know. With MSVC, they emit a proprietary debug information format (in .pdb files) that isn't documented. I am sure a native windows plug-in could be made to support binaries built with gcc or clang, but I don't believe anyone has done this yet.

Greg

9

>
> Hi,
>
> I tried both building lldb with MSVC and with MinGW both failed to debug
native Windows executables (I actually tried 3 types of executables, 1
built with MinGW, 1 with clang 3.4 and 1 with Visual Studio)
>
> This is the error I am getting:
>
> $ lldb D:/src/TestArea/ClangVC/Debug/ClangVC.exe
> error: 'D:/src/TestArea/ClangVC/Debug/ClangVC.exe' doesn't contain any
'host' platform architectures:
> (lldb)
>
> So the question is:
> ​Is it possible to use lldb on Windows (for local debugging not remote
debugging)

No, we currently don't support native debugging on windows as far as I know

​Thanks for the clarifications.
​

10

I suppose I should merge my branch back to LLDB trunk at some point?
I could rebase & merge the new ProcessWindows and DynamicLoaderWindows plugins (https://github.com/xen2/lldb/commit/515956244784a9162183a6135068e893ba994532) and keep the other LLDB changes aside for now if they need further discussion?

Or any similar work in the way?

11

Hey Virgile,

I think you’ll need to talk to Zach for this. There has been quite a lot of changes, and I think some of the changes may impact significantly on your merge.

I’m not up to date with all of the changes now in trunk, so best to ask him. I could be wrong and it be easy :slight_smile:

Colin

12

You are welcome to try to upstream some of your work, but given the work I’ve done on refactoring the codebase, it might be difficult to do a straight rebase of your fork onto tip. Instead of a rebase, which would force difficult merges at numerous points, perhaps easier would be to sync to tip and then merge small pieces of your branch directly across. That said, work on LLDB has become more active recently, in part because of me working on Windows, but due to others as well, and so it may not be appropriate to do one huge merge with thousands of lines making it difficult to review. Instead, it might be more appropriate (albeit more of an effort on your part) to merge small, isolated pieces of your branch at a time.

Can you summarize what you’ve done on your branch and how much actual work you think it is? Any limitations or known places where you dont’ provide all the same functionality that LLDB does for other platforms?

13

Sorry for answering much later (was dragged into other LLVM subprojects recently), but figured I better get this merged before it diverges too much and get lost… (to avoid someone ending up reimplementing everything again from scratch).

Anyway, the biggest part of this branch was this commit:
https://github.com/xen2/lldb/commit/515956244784a9162183a6135068e893ba994532"

It basically added a working implementation of ProcessWindows. It was good enough to debug actual simple Win32 processes that I compiled with GCC (might work on much bigger ones, didn’t try it), including multithread single stepping, breakpoints, variable watches, disassembler, etc… Also, if user breaks inside a Win32 call, it could usually step out of it properly as well (but might need improvements – Win32 ABI support seems to have improved a lot as well in the meantime in LLVM, Clang and GCC/Mingw32 so situation might be easier.

However some specific parts probably needed rewrite/review.
Considering it works as a whole, I figured it would be better to first merge it, and rewrite the necessary part while doing the review (probably various part would need better implementations, I might have misunderstood some LLDB internals since I was discovering the project).

Actually I have already split mostly everything that was not part of ProcessWindows plugin itself, and got it merged to trunk in the past (2013/early 2014).

If I were to split it more, I am afraid it would probably be hard to test/improve because it wouldn’t work and be testable (actually it is not that huge, ProcessWindows.cpp, the probably only meaningful file of this commit, is less than a 1000 line).

But I wouldn’t mind trying to split it if people prefer it that way (as long as it gets reviewed and merged smoothly).

Anyway let me know if you want me to try rebase and/or merge it (or not).

14

Thanks for the response. I definitely think it would be great to have this functionality in. Originally when I started working on LLDB my goal was just to get the test suite up and running 100% (even if all the tests don’t pass, at least the test infrastructure would run tests and correctly report pass/fail). So in hindsight now I’m glad I took this approach instead of working on getting some basic debugging functionality implemented, because then our work would have overlapped. :slight_smile:

In order to get just very primitive functionality working though, I also created a ProcessWindows, but the only function I implemented was DoLaunch. So it looks like that will be your biggest merge conflict. You may also have some issues with method names (I moved alot of stuff from the Host:: namespace to different places) but that is mostly just syntactic and not too much different semantically.

Let me know if you have any difficulties merging it to trunk, I’m happy to help get this in and review it pre commit.

15

Zachary Turner schreef op 21-10-2014 om 21:24:

Thanks for the response. I definitely think it would be great to have
this functionality in. Originally when I started working on LLDB my
goal was just to get the test suite up and running 100% (even if all the
tests don't pass, at least the test infrastructure would run tests and
correctly report pass/fail). So in hindsight now I'm glad I took this
approach instead of working on getting some basic debugging
functionality implemented, because then our work would have overlapped. :slight_smile:

Does that work now? The testing? I have an SBFunction related patch that pretty much depends on testability :slight_smile:

16

It’s getting there. I know of only 4 issues with the test suite currently that I’m working on fixing. There might be more, but when I run “ninja check-lldb” these are the only ones that happen. They are, in no particular order:

PutSTDIN doesn’t work right (may have been fixed due to a recent patch by Greg Clayton, need to re-verify)
dotest.py -q --arch=i686 --executable D:/src/llvm/build/ninja/bin/lldb.exe -s D:/src/llvm/build/ninja/lldb-test-traces -u CXXFLAGS -u CFLAGS -C D:\src\llvm\build\ninja\bin\clang.exe -p TestProcessIO.py D:\src\llvm\tools\lldb\test\python_api\process\io

ProcessWindows doesn’t know how to signal when process ends, hangs in Process::WaitForProcessToStop (Working on this one currently, should be the next one I fix)
dotest.py -q --arch=i686 --executable D:/src/llvm/build/ninja/bin/lldb.exe -s D:/src/llvm/build/ninja/lldb-test-traces -u CXXFLAGS -u CFLAGS -C D:\src\llvm\build\ninja\bin\clang.exe -p TestCallWithTimeout.py D:\src\llvm\tools\lldb\test\expression_command\timeout

Test suite generates python errors, not clear why.
dotest.py -q --arch=i686 --executable D:/src/llvm/build/ninja/bin/lldb.exe -s D:/src/llvm/build/ninja/lldb-test-traces -u CXXFLAGS -u CFLAGS -C D:\src\llvm\build\ninja\bin\clang.exe -p TestPlatformCommand.py D:\src\llvm\tools\lldb\test\functionalities\platform

RunShellCommand doesn’t work, can’t resolve cmd.exe correctly. (Already submitted r220217 that partially fixes this, there may or may not be more to do)
D:\src\llvm\tools\lldb\test/dotest.py -q --arch=i686 --executable D:/src/llvm/build/ninja/bin/lldb.exe -s D:/src/llvm/build/ninja/lldb-test-traces -u CXXFLAGS -u CFLAGS -C D:\src\llvm\build\ninja\bin\clang.exe -p TestPlatformCommand.py D:\src\llvm\tools\lldb\test\functionalities\platform

Alongside each test I’ve given the exact command line you can use to reproduce the error. Feel free to take a look if you want :slight_smile: The way I found all these was to just run “ninja check-lldb” on Windows, then attach a debugger to crashed or deadlocked processes.

I recently hit a new error which has blocked everything, and has to do with the way clang finds cl to fallback to. I’m working on a few patches to clang to make its fallback logic smarter, and once I get all that worked out I’ll get back to this.

17

Also, once it’s working, I plan to set up a Windows build bot that’s connected to the main llvm waterfall, and have it run automatically each time a new patch is submitted, similar to how the build bots work for the other platform. That’s my ultimate goal, just making sure that if the build breaks (either compilation or with test regressions) we know about it :slight_smile:

18

I’m actually starting to work on this now because it’s the next thing causing tests to fail for me whiel I try to get the test suite working.

Some of the changes I’ve made conflict with yours on a fundamental level, so I’m working through your patch and trying to incorporate the stuff you did in a way that fits with what I’ve already done. It looks like conceptually what we’ve done is pretty similar, just implemented differently.

Anyway I will take a look at this for now unless you have some objections. Hopefully can get everything you’ve done here merged up.

19

Sure, sounds good!

Very happy somebody is taking this over (I bootstrapped/prototyped it at the time because I wanted to check feasability of good debugging support for this C#=>LLVM project I was planning to start: https://github.com/xen2/SharpLang ).
Adding windows build bot was also something I wanted to do but never got around to do it.

Feel free to ask me if you need any explanation/details about my implementation, or if you need any help.