<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Convenience variables (lldb.debugger, etc) are broken after copying lldb install tree."
href="https://bugs.llvm.org/show_bug.cgi?id=39054">39054</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Convenience variables (lldb.debugger, etc) are broken after copying lldb install tree.
</td>
</tr>
<tr>
<th>Product</th>
<td>lldb
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Windows NT
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>All Bugs
</td>
</tr>
<tr>
<th>Assignee</th>
<td>lldb-dev@lists.llvm.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>vadimcn@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>Repro:
1. Build LLDB as normal on Windows.
2. cd %build%\lib\site-packages\lldb
3. copy _lldb.pyd temp.pyd && del _lldb.pyd && move temp.pyd _lldb.pyd
4. start lldb, execute 'script print(lldb.debugger.IsValid())'
The output will be False. If you skip step #3 would be True.
Why this happens:
_lldb module gets created twice: once by liblldb upon a call to
SBDebugger::Initialize() and once when loaded as _lldb.pyd by Python
interpreter. Because on Windows dynamic modules do not share global symbols,
stuff that relies on module globals becomes subtly broken. For example,
debugger objects created by liblldb, cannot be found by a Python module via
SBDebugger::FindDebuggerWithID(), which ultimately results in broken
`lldb.debugger`.
Why it works without step #3:
_lldb.pyd and liblldb.dll are actually the same binary, so LLDB build script
symlinks the former to the latter (to save disk space?). On Windows, proper
symbolic links did not exist until relatively recently, so the build script
used hard-linking instead. Well, it just so happens that Windows module loader
will consider two hard links pointing to the same file to be *the same dynamic
module*, and will *not* load it the second time. Probably has something to do
with how memory mapping subsystem keeps track of mapped files.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>