[lldb-dev] [Bug 39054] New: Convenience variables (lldb.debugger, etc) are broken after copying lldb install tree.

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=39054

            Bug ID: 39054
           Summary: Convenience variables (lldb.debugger, etc) are broken
                    after copying lldb install tree.
           Product: lldb
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: lldb-dev at lists.llvm.org
          Reporter: vadimcn at gmail.com
                CC: llvm-bugs at lists.llvm.org

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20180923/3b9a037f/attachment.html>