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

[Zachary Turner]

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
:)

On Tue, Oct 21, 2014 at 1:49 PM, Zachary Turner <zturner at google.com> wrote:

> 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 :)  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.
>
>
>
> On Tue, Oct 21, 2014 at 1:16 PM, Carlo Kok <ck at remobjects.com> wrote:
>
>>
>>
>> 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.
>>> :)
>>>
>>
>> Does that work now? The testing? I have an SBFunction related patch that
>> pretty much depends on testability :)
>>
>> --
>> Carlo Kok
>>
>> _______________________________________________
>> 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/20141021/f613d3f1/attachment.html>