<div dir="ltr">Hello,<br><br>Many of the changes in the windows branches are actually contained in this patch (r189107).<div>Did you have any changes on top of the windows branch?<br></div><div><br>Since I work on the same stuff currently, I better lay out what I am doing and what's my current current status, so that there is no duplication of efforts. I hope we can work together on this!</div>
<div><br></div><div>I recently restarted the windows port from scratch using what's already been done in the windows branch to first support MinGW and then MSVC with incremental changes, so that it can be merged step by step into trunk (much more easy to get it merged than a single huge patch).</div>
<div><br></div><div>Also, a MinGW build is useful since it could be more easily added to the buildbot and test suite.<br></div><div>And since MinGW and MSVC changes have many common parts, I figured it would be good to do both of them in the proper order (more easy to add MSVC on top of MinGW than the opposite -- windows branch was only targeting MSVC as far as I know, so it wasn't making difference between #ifdef _WIN32 and #ifdef _MSC_VER).</div>
<div><br></div><div>The first MinGW patch just got accepted, but I still got the MSVC patch that I need to clean up and get reviewed.</div><div><br></div><div>Hopefully this should result in a much smaller and cleaner patch for MSVC, since it was done together with MinGW changes in mind. Also it should avoid the merging (which might be difficult on top of latest changes and MinGW patch).</div>
<div><br></div><div>Note that the MinGW patch also includes some changes that were not part of the windows branch to provide a better windows support (esp. file case resolution, etc...).</div><div><br></div><div>I currently target MSVC12 since it is supposed to have better C++11 support, but going from MSVC12 to MSVC11 is only a few changes.</div>
<div><br></div><div>If everybody is OK to go this way, most of the windows branch will end up being merged.</div><div>If people are interested in helping, I could publish the branch so we could work on it together.</div>
<div>
<br></div><div>After that there might still be some changes in the windows branch that I didn't do, so it would be good to evaluate what's left (but probably not so much).<br></div><div><br></div><div>As soon as python support is added, the lldb executable and the test suite should work as well.<br>
</div><div><br></div><div>Now, I happen to be working on the lldbProcessWindows/lldbDynamicLibraryWindows plugins. Many features are working (stack trace, breakpoints, stepping, disassembly, threads, locals, etc...).</div>
<div>I currently use it in a MSVC DebugEngine plugin. It's still early stage but it's starting to work.</div><div><br></div><div>Let me know what you think!</div><div><br></div><div>Virgile<br><br>>I just checked the the MinGW patch was submitted with revision 189107.<br>
><br>>So you can now merge top of tree into the windows branch and start submitting patches.<br>><br>>A few things to keep in mind are that any windows (host specific) features need to be abstracted into the lldb_private::Host layer in a system agnostic interface. The files that implement the features should be in source/Host/windows. The only exceptions is in the .cpp files of plugins (like ConnectionFileDescriptor.cpp) where it is ok, in the .cpp file, to add windows specific function calls and logic.<br>
><br>>I look forward to seeing the upcoming patches and getting windows support into top of tree.<br>><br>>Greg<br>><br>>On Aug 23, 2013, at 9:28 AM, Greg Clayton <gclayton at <a href="http://apple.com">apple.com</a>> wrote:<br>
><br>>> <br>>> On Aug 23, 2013, at 9:03 AM, Colin Riley <colin at <a href="http://codeplay.com">codeplay.com</a>> wrote:<br>>> <br>>>> Hello all, Codeplay reporting in.<br>>>> <br>
>>> We want to do the merge and unification between the windows and trunk branches of LLDB. We are doing lots of work with LLDB and it seems the most sensible thing do to given the amount of effort we currently undertake to maintain both branches locally.<br>
>>> <br>>>> Obviously the merge must not break the buildbots currently running on the non-windows target. Additionally, the tests do not run at all under windows, which is an issue we will need to look into solving. It will be difficult given the fact the windows branch itself will not be able to actually debug on windows, however we'd like to do this to the point where the windows branch can be closed.<br>
>>> <br>>>> Our questions to folk on here: what would be accepted in terms of support for this? It could be quite a large patch, and touch many areas, but it is something that needs done to further advance LLDB support for other architectures and platforms. It will also include changes to the driver so a command line frontend is available for windows.<br>
>> <br>>> We currently have a MinGW patch that is in the process of trying to get submitted, so I would hold off on any commits/patches until this makes it in. The patch is currently causing deadlocks on linux buildbots. Once this is in, we can then merge top of tree with the windows branch prior to submitting patches for the final windows merge that will allow us to remove the windows branch.<br>
>> <br>>>> <br>>>> Are there any reservations folk have for this, and if so, can we overcome them?<br>>> <br>>> So first we need to get the MinGW patch submitted, then we can proceed.<br>
>> <br>>> Greg<br>>> <br>>>> <br>>>> Many thanks,<br>>>> <br>>>> Colin<br>>>> (cc'd with Deepak, who is also involved with this)<br>>>> <br>>>> -- <br>
>>> Colin Riley<br>>>> Games Technology Director<br>>>> <br>>>> Codeplay Software Ltd<br>>>> 45 York Place, Edinburgh, EH1 3HP<br>>>> Phone: +44 131 466 0503<br>>>> Fax: +44 131 557 6600<br>
>>> Website: <a href="http://www.codeplay.com">http://www.codeplay.com</a><br>>>> Twitter: @codeplaysoft<br>>>> <br>>>> This email and any attachments may contain confidential and /or privileged information and is for use by the addressee only. If you are not the intended recipient, please notify Codeplay Software Ltd immediately and delete the message from your computer. You may not copy or forward it,or use or disclose its contents to any other person. Any views or other information in this message which do not relate to our business are not authorized by Codeplay software Ltd, nor does this message form part of any contract unless so stated.<br>
>>> As internet communications are capable of data corruption Codeplay Software Ltd does not accept any responsibility for any changes made to this message after it was sent. Please note that Codeplay Software Ltd does not accept any liability or responsibility for viruses and it is your responsibility to scan any attachments.<br>
>>> Company registered in England and Wales, number: 04567874<br>>>> Registered office: 81 Linkfield Street, Redhill RH1 6BY<br>>>> <br>>>> _______________________________________________<br>
>>> lldb-dev mailing list<br>>>> lldb-dev at <a href="http://cs.uiuc.edu">cs.uiuc.edu</a><br>>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
>> <br>>> _______________________________________________<br>>> lldb-dev mailing list<br>>> lldb-dev at <a href="http://cs.uiuc.edu">cs.uiuc.edu</a><br>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a></div>
</div>