[lldb-dev] [Bug 39054] New: Convenience variables (lldb.debugger, etc) are broken after copying lldb install tree.
lldb-dev at lists.llvm.org
Sun Sep 23 11:04:27 PDT 2018
Bug ID: 39054
Summary: Convenience variables (lldb.debugger, etc) are broken
after copying lldb install tree.
OS: Windows NT
Component: All Bugs
Assignee: lldb-dev at lists.llvm.org
Reporter: vadimcn at gmail.com
CC: llvm-bugs at lists.llvm.org
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
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.
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev