6 months ago I worked on LLDB to add Windows process debugging support.
I had to put this project little bit aside for a little bit. Now that I have some more time to focus on that project again, I wanted to share what I have been doing so far, and hopefully as it gets more mature it would be great to have it merged in trunk later.
So far I pushed most of my changes on github:
The most important commit is probably “Added ProcessWindows and DynamicLoaderWindows plugins.”. Some of the commits might be only temporary (needed for debugging to work). Some others commits are trivial/minor and could probably be cherry-picked immediately in trunk.
It is far from being ready to be merged yet (unpolished commits, lot of file rearrange/rename, code sharing, cleanup and comments to do here and there).
Also, at the time (might have been fixed yet), I used Linux implementation as a guideline but noticed it didn’t seem to work for multithreading (StopInfo mixing up each other). As a result I had to change some stuff to have multithreading working. That might be something that could be interesting to have back on Linux as well.
Status: I am now able to use LLDB as a library to actually debug real windows processes (including stack traces, variables, multithreading, etc…) on simple executables (compiled with either gcc with -gdwarf-2, or clang).
Note: I might force push the branch msvc12 on github since I want to rewrite some commits and rebase. If people are interested in helping, please let me know and I would stop doing that.
Hope it will help starting the effort to have a full debugging support on Windows!
That is great new about the windows branch you have. It would be good to probably stage this as you stated in this order:
1 - submit patches to top of tree lldb for basic things you found that aren't related to windows
2 - submit a patch for windows native debugging
As you said, it will be good to get all of the organization done on your end the way you want it prior to submitting the patches. And you are correct that multi-threading on Linux has long been fixed. As long as you are in sync with the current SVN top of tree (or our read only GIT top of tree), your patches should be easy to submit.
We would love to be able to support native windows debugging in LLDB for GCC and clang produced binaries.
This looks great! We had recently started on our own Windows Process plugin implementation, porting code we had used in a simple custom debugger to LLDB, however I think it would make sense to combine our efforts. I would be happy to help stabilize what you have so far, I built locally from your repo and much of the process control works great though I haven’t had any luck getting debug info in stack traces in a few simple apps built with gcc (-gdwarf-2) or with clang using lldb.exe yet.
What we’re aiming for is slightly different than you, we’re mostly interested in the ability to parse ELF/Dwarf debug info from code produced by MCJIT since the bulk of our software currently needs to be compiled with MSVC. This relies on a JIT support patch (currently for Linux) which hasn’t yet been submitted upstream, though your work here is probably the push required for me to get that done.
I will take a pass through some samples on this end and take note of any issues I come across and then start looking into them. Let me know how you would like to coordinate work here (assuming you would like to coordinate) and we can go from there.
Sure, that would be great to combine effort! Quite happy people are willing to join, it’s quite a huge task. And your goal being little bit different is good to have more test cases and features.
I’m quite open about how to coordinate. On my side, I think I just need a few days to clean up and rearrange commits little bit more before starting a proper branch, then we could start to work from that?
Where would you prefer to work? SVN? Github?
Actually I have never tried lldb.exe directly, I use it as a library, so I didn’t really expect it to work – good to know process control was OK at least!
Also, some scenarios that used to work for me 6 months ago don’t work anymore now, so that might be related as well. I’ll try to fix those regressions quickly so that your work doesn’t bump into them.
That sounds great, just let me know when you feel the repo is in a good state and I’ll take another look. My preference is github (username andrewmacp) but I’m open if you prefer something else. Talk soon!
Sorry, took me some time to get around it, but I have finally took the time to:
- Commit as many trivial changes as possible into LLDB trunk.
- Update my code to latest LLDB changes.
- Rearrange the rest and put them on github for review and accept external help/contributions.
Feel free to contact me if you want commit access!
(Andrew, I added you as collaborator)
Some of the commits that affects LLDB might need review and be delayed, but the main commit that adds ProcessWindows should probably be merged soon to avoid divergence and make contributions easier.
That sounds great, thanks Virgile! I may not get a chance until early week but I will definitely try this out to see where it’s at. Nice work!
I gave this a go and it’s working with simple gcc-cygwin compiled executables, nice!
I went to try and integrate some early PDB loading work I did into it (it goes via DIA), but sadly looks like my home machine has decided PDBs are evil and, well, corrupted my local repo! It was some time ago I looked at it (at least November last year). I’ll probably have a look at seeing if that can work again, at least symbol information would be a great start. I think I’d only got as far as symbols anyway.
Again, nice work! Need to work together at getting this back to trunk.
Good to know it worked well for somebody else (esp. since I have never tried it through the lldb.exe client, only as a library).
Anyway, thanks for helping out! Let me know if you need any commit permissions on github, and if you have any idea on how to proceed from now on…