[lldb-dev] Is anyone using lldb on Windows to debug a _Windows_ application

Thu Nov 6 13:29:16 PST 2014

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 <virgile.bello at gmail.com>
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 <zturner at google.com> 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 <virgile.bello at gmail.com>
>> 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 <eran.ifrah at gmail.com> wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Mon, Jun 16, 2014 at 9:12 PM, Greg Clayton <gclayton at apple.com>
>>>> wrote:
>>>>
>>>>>
>>>>> > On Jun 14, 2014, at 3:12 AM, Eran Ifrah <eran.ifrah at gmail.com>
>>>>> 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
>>>> lldb-dev at cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> lldb-dev mailing list
>>> lldb-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141106/c8e986a2/attachment.html>