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. On Tue Oct 21 2014 at 7:50:50 AM Virgile Bello <[email protected]> wrote: > 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). > > On 28 August 2014 00:11, Zachary Turner <[email protected]> wrote: > >> 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? >> >> >> On Tue, Aug 26, 2014 at 5:36 PM, Virgile Bello <[email protected]> >> wrote: >> >>> 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? >>> >>> >>> On 17 June 2014 05:45, Eran Ifrah <[email protected]> wrote: >>> >>>> >>>> >>>> >>>> On Mon, Jun 16, 2014 at 9:12 PM, Greg Clayton <[email protected]> >>>> wrote: >>>> >>>>> >>>>> > On Jun 14, 2014, at 3:12 AM, Eran Ifrah <[email protected]> >>>>> wrote: >>>>> > >>>>> > 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. >>>> >>>> >>>>> . 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 >>>>> >>>>> >>>> >>>> >>>> -- >>>> Eran Ifrah >>>> Author of codelite, a cross platform open source C/C++ IDE: >>>> http://www.codelite.org >>>> wxCrafter, a wxWidgets RAD: http://wxcrafter.codelite.org >>>> >>>> _______________________________________________ >>>> lldb-dev mailing list >>>> [email protected] >>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >>>> >>>> >>> >>> _______________________________________________ >>> lldb-dev mailing list >>> [email protected] >>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >>> >>> >> >
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
