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

Thu Nov 6 18:19:36 PST 2014

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.

On 7 November 2014 06:29, Zachary Turner <zturner at google.com> wrote:

> 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/20141107/9e5493c1/attachment.html>