<div dir="ltr">It won't be loaded into a<br><br><div class="gmail_quote">On Wed, Feb 25, 2015 at 11:05 AM Ted Woodward <<a href="mailto:ted.woodward@codeaurora.org">ted.woodward@codeaurora.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">The icon for pcbuild.sln has a 9 in it; I assumed that meant VS 2009. Silly me </span><span style="font-size:11.0pt;font-family:Wingdings;color:#1f497d">J</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I’m not confident that a DLL built with VS 2008 that has any C++ code will not crash when loaded into a program built with VS2013, because of the incompatible C++ library issue.</span></p></div></div></blockquote><div>This is actually a fairly easy problem to solve.  The interface boundary between the VS 2008 DLL and the VS2013 (or whatever version) stuff simply needs to have some rules on it.  C++ classes are fine, the only thing that isn't fine is allocating memory one one side which is freed on the other side.  So you can have all the C++ you want, you just have to keep that C++ in the DLL, and not give the user access to any of its internal state that would cause code on the other side to trigger a free.</div><div><br></div><div>This sounds scary, but in practice it's really not that difficult.  For example, suppose you have ScriptInterpreterPython defined in the DLL. It derives from a ScriptInterpreter base interface.  You don't expose ScriptInterpreterPython outside the DLL, only ScriptInterpreter.  Anyone who uses a pointer to ScriptInterpreter is fine, doesn't matter what side of the boundary they're on, because the actual code for the implementation of these methods lives in the DLL.  If you expose the full object though, you run the risk of someone passing it by value, then have news on one side and deletes on the other.  Another thing you can't do is pass std::strings or similar by value (which also means you can't return them from dllexported functions).</div><div><br></div><div>Since a side benefit of this refactor is to open the door for someone dropping in a new embedded interpreter though, we would want to hide the implementation details of the interpreter anyway, so this problem is solved as a natural consequence of the design.  All we expose is a pointer to the base interface, hide the rest, and pass the pointer across boundaries, making it clear that the pointer is always owned by the DLL.</div><div><br></div><div>Lots of Microsoft system DLLs have C++ code in them, so this isn't really an issue in practice as long as you define your interface.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">How do we get around the debug-vs-release issue that makes us have python27_d.dll on a debug build right now?</span></p></div></blockquote><div>The reason we need python27_d.dll on a debug build right now is because all of LLDB is compiled into the a single massive DLL that is basically lldb.exe but as a dll that python can load.  So that's actually the point of the split.  Python only needs just enough that it can call into LLDB's public API.  The C++ implementation of the public API classes are already dllexported, so the SWIG generated code that wraps those will just call into some dllexported methods, across the boundary, and into code that is compiled with VS2013.  </div><div><br></div><div>If a developer is hacking on the extension module itself (e.g. the implementation of ScriptInterpreterPython), he/she will need to compile python himself with VS2013 in order to step through the code.  <span style="font-size:13.1999998092651px">But that code is is low-traffic code and relatively stable.  </span></div><div><span style="font-size:13.1999998092651px"><br></span></div><div>Think about it like kernel32.dll and yourdll.dll.  Who knows what version of the compiler kernel32.dll is built with.  But they can call into each other no problem, and you can still debug your program with no problem, even though kernel32 is a release binary.</div><div><span style="font-size:13.1999998092651px"><br></span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u><u></u></span></p></div></div><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">--<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Qualcomm Innovation Center, Inc.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p></div></div><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Zachary Turner [mailto:<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>] <br><b>Sent:</b> Wednesday, February 25, 2015 12:35 PM</span></p></div></div><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><br><b>To:</b> Ted Woodward; Reid Kleckner; Vince Harron<br><b>Cc:</b> <a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br><b>Subject:</b> Re: [lldb-dev] RFC: Separation of embedded Python from the rest of LLDB.<u></u><u></u></span></p></div></div><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">Just to be clear, with solution #1 proposed in the original message, then your option #3 is guaranteed to work.  (also, minor pedantic nit - it's VC 2008, not 2009).  You won't have to build python, it will literally just work.  The reason for this is that I will have the CMake build automatically compile the separate shared library with Microsoft's toolchain whose <a href="https://www.microsoft.com/en-us/download/details.aspx?id=44266" target="_blank">sole purpose in life is to build python extension modules</a> that interoperate with the binary release of python 2.7<u></u><u></u></p></div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">On Wed, Feb 25, 2015 at 10:19 AM Ted Woodward <<a href="mailto:ted.woodward@codeaurora.org" target="_blank">ted.woodward@codeaurora.org</a>> wrote:<u></u><u></u></p><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><div><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I’m all for making it simpler. Believe me, coming up with my solution was a pain. But once I built Python, I was done with that part. We save off the binaries/modules, build against them, then copy them into the lib directory. I’ve got a patch that lets the builder set a default PYTHONHOME and PYTHONPATH in cmake, and if they don’t exist when LLDB is run it sets them in the environment based on the defaults. </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">We need to build Python on Windows with VS2013 because the binaries from <a href="http://python.org" target="_blank">python.org</a> are built with VS 2009, and will cause crashes in LLDB built with VS2013 because of incompatibilities between the 2009 C++ library and the 2012 C++ library. Our options seem to be:</span><u></u><u></u></p><p><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">1)</span><span style="font-size:7.0pt;color:#1f497d">      </span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Build Python and save an artifact</span><u></u><u></u></p><p><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">2)</span><span style="font-size:7.0pt;color:#1f497d">      </span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Require everyone build Python</span><u></u><u></u></p><p><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">3)</span><span style="font-size:7.0pt;color:#1f497d">      </span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Separate the Python interface into its own shared library and hope that when it calls the 2009 C++RT it won’t crash</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I went for #1 for Hexagon LLDB because I couldn’t rely on the user having the correct Python installed, on Windows or Linux.</span><u></u><u></u></p></div></div><div><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">--</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Qualcomm Innovation Center, Inc.</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p></div></div><div><div><p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Zachary Turner [mailto:<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>] <br><b>Sent:</b> Wednesday, February 25, 2015 11:47 AM<br><b>To:</b> Ted Woodward; Reid Kleckner; Vince Harron</span><u></u><u></u></p></div></div><div><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><br><b>Cc:</b> <a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br><b>Subject:</b> Re: [lldb-dev] RFC: Separation of embedded Python from the rest of LLDB.</span><u></u><u></u></p></div></div><div><div><p class="MsoNormal"> <u></u><u></u></p><div><p class="MsoNormal" style="margin-bottom:12.0pt"> <u></u><u></u></p><div><p class="MsoNormal">On Wed, Feb 25, 2015 at 9:39 AM Ted Woodward <<a href="mailto:ted.woodward@codeaurora.org" target="_blank">ted.woodward@codeaurora.org</a>> wrote:<u></u><u></u></p></div></div></div></div><div><div><div><div><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt"><div><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Saying you can’t build Python with VS2013 isn’t true. I did. I’m having issues with some of the bindings (specifically “print lldb.debugger” gives “No value”, even though it’s there), but for the most part it works.</span><u></u><u></u></p></div></blockquote><div><p class="MsoNormal">Well sure, I did too.  As it's the only way to run tests.  I think his point is just that it's a big barrier to entry.  I've got 3 guys who sit around me.  One works on the windows linker, and the other two are responsible for much of clang-cl.  None of them feel like going through these hoops to build LLDB, even though there's bugs in LLDB on Windows that their expertise would be a great asset in making some progress on.<u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal">I mean yes I could do it for them, and yes they could ultimately do it themselves, but the point is that it shouldn't be this difficult.  What about people without the same amount of technical background, but who still want to hack around on the debugger?  I dont' want to discourage anyone from being able to work on the project.  Barriers close doors. I want the doors to be open.<u></u><u></u></p></div></div></div></div></div></blockquote></div></div></div></blockquote></div></div>