[Lldb-commits] [lldb] r344474 - Fix double import of _lldb module.

2018-10-14 Thread Vadim Chugunov via lldb-commits
Author: vadimcn
Date: Sun Oct 14 00:24:56 2018
New Revision: 344474

URL: http://llvm.org/viewvc/llvm-project?rev=344474&view=rev
Log:
Fix double import of _lldb module.

Fix llvm.org/pr39054:
- Register _lldb as a built-in module during initialization of script 
interpreter,
- Reverse the order of imports in __init__.py: first try to import by absolute 
name, which will find the built-in module in the context of lldb (and other 
hosts that embed liblldb), then try relative import, in case the module is 
being imported from Python interpreter.

This works for SWIG>=3.0.11; before that, SWIG did not support custom module 
import code.

Differential revision: https://reviews.llvm.org/D52404

Modified:
lldb/trunk/scripts/lldb.swig

lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp

Modified: lldb/trunk/scripts/lldb.swig
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/lldb.swig?rev=344474&r1=344473&r2=344474&view=diff
==
--- lldb/trunk/scripts/lldb.swig (original)
+++ lldb/trunk/scripts/lldb.swig Sun Oct 14 00:24:56 2018
@@ -41,12 +41,12 @@ Older swig versions will simply ignore t
 */
 %define MODULEIMPORT
 "try:
-# Try a relative import first
-from . import $module
+# Try an absolute import first.  If we're being loaded from lldb,
+# _lldb should be a built-in module.
+import $module
 except ImportError:
-# Maybe absolute import will work (if we're being loaded from lldb, it
-# should).
-import $module"
+# Relative import should work if we are being loaded by Python.
+from . import $module"
 %enddef
 // These versions will not generate working python modules, so error out early.
 #if SWIG_VERSION >= 0x030009 && SWIG_VERSION < 0x030011

Modified: 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp?rev=344474&r1=344473&r2=344474&view=diff
==
--- 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp 
(original)
+++ 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp 
Sun Oct 14 00:24:56 2018
@@ -132,6 +132,9 @@ public:
 
 InitializePythonHome();
 
+// Register _lldb as a built-in module.
+PyImport_AppendInittab("_lldb", g_swig_init_callback);
+
 // Python < 3.2 and Python >= 3.2 reversed the ordering requirements for
 // calling `Py_Initialize` and `PyEval_InitThreads`.  < 3.2 requires that you
 // call `PyEval_InitThreads` first, and >= 3.2 requires that you call it last.


___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D52404: Prevent double import of _lldb module

2018-10-14 Thread Vadim Chugunov via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL344474: Fix double import of _lldb module. (authored by 
vadimcn, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D52404?vs=166627&id=169595#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D52404

Files:
  lldb/trunk/scripts/lldb.swig
  lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp


Index: 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
===
--- 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -132,6 +132,9 @@
 
 InitializePythonHome();
 
+// Register _lldb as a built-in module.
+PyImport_AppendInittab("_lldb", g_swig_init_callback);
+
 // Python < 3.2 and Python >= 3.2 reversed the ordering requirements for
 // calling `Py_Initialize` and `PyEval_InitThreads`.  < 3.2 requires that you
 // call `PyEval_InitThreads` first, and >= 3.2 requires that you call it last.
Index: lldb/trunk/scripts/lldb.swig
===
--- lldb/trunk/scripts/lldb.swig
+++ lldb/trunk/scripts/lldb.swig
@@ -41,12 +41,12 @@
 */
 %define MODULEIMPORT
 "try:
-# Try a relative import first
-from . import $module
+# Try an absolute import first.  If we're being loaded from lldb,
+# _lldb should be a built-in module.
+import $module
 except ImportError:
-# Maybe absolute import will work (if we're being loaded from lldb, it
-# should).
-import $module"
+# Relative import should work if we are being loaded by Python.
+from . import $module"
 %enddef
 // These versions will not generate working python modules, so error out early.
 #if SWIG_VERSION >= 0x030009 && SWIG_VERSION < 0x030011


Index: lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
===
--- lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -132,6 +132,9 @@
 
 InitializePythonHome();
 
+// Register _lldb as a built-in module.
+PyImport_AppendInittab("_lldb", g_swig_init_callback);
+
 // Python < 3.2 and Python >= 3.2 reversed the ordering requirements for
 // calling `Py_Initialize` and `PyEval_InitThreads`.  < 3.2 requires that you
 // call `PyEval_InitThreads` first, and >= 3.2 requires that you call it last.
Index: lldb/trunk/scripts/lldb.swig
===
--- lldb/trunk/scripts/lldb.swig
+++ lldb/trunk/scripts/lldb.swig
@@ -41,12 +41,12 @@
 */
 %define MODULEIMPORT
 "try:
-# Try a relative import first
-from . import $module
+# Try an absolute import first.  If we're being loaded from lldb,
+# _lldb should be a built-in module.
+import $module
 except ImportError:
-# Maybe absolute import will work (if we're being loaded from lldb, it
-# should).
-import $module"
+# Relative import should work if we are being loaded by Python.
+from . import $module"
 %enddef
 // These versions will not generate working python modules, so error out early.
 #if SWIG_VERSION >= 0x030009 && SWIG_VERSION < 0x030011
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D53255: Fix: Assertion failed: (!m_first_die || m_first_die == m_die_array.front()), function ExtractDIEsRWLocked

2018-10-14 Thread Jan Kratochvil via Phabricator via lldb-commits
jankratochvil created this revision.
jankratochvil added reviewers: clayborg, labath.
jankratochvil added a project: LLDB.
Herald added subscribers: JDevlieghere, aprantl.

xbolva00 bugreported $subj 
It can happen only from the line:

  m_die_array.back().SetEmptyChildren(true);

In the case `DW_TAG_compile_unit` has `DW_CHILDREN_yes` but there is only 0 
(end of list, no children present). Therefore the assertion can fortunately 
happen only with a hand-crafted DWARF or with DWARF from some suboptimal 
compilers.
I could not find a reproducer with unpatched LLDB code, could you provide what 
LLDB commands could reproduce that? A debuggee binary which can reproduce it 
is: lldb-repro.tar.xz 


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D53255

Files:
  source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp


Index: source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
===
--- source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
+++ source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
@@ -261,7 +261,11 @@
   }
 
   if (!m_die_array.empty()) {
-lldbassert(!m_first_die || m_first_die == m_die_array.front());
+if (m_first_die) {
+  // Only needed for the assertion.
+  m_first_die.SetEmptyChildren(m_die_array.front().GetEmptyChildren());
+  lldbassert(m_first_die == m_die_array.front());
+}
 m_first_die = m_die_array.front();
   }
 


Index: source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
===
--- source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
+++ source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
@@ -261,7 +261,11 @@
   }
 
   if (!m_die_array.empty()) {
-lldbassert(!m_first_die || m_first_die == m_die_array.front());
+if (m_first_die) {
+  // Only needed for the assertion.
+  m_first_die.SetEmptyChildren(m_die_array.front().GetEmptyChildren());
+  lldbassert(m_first_die == m_die_array.front());
+}
 m_first_die = m_die_array.front();
   }
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D46810: 3/3: Fix DWARFUnit::GetUnitDIEPtrOnly stale pointer

2018-10-14 Thread Jan Kratochvil via Phabricator via lldb-commits
jankratochvil added inline comments.



Comment at: lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp:179
+  if (!m_die_array.empty()) {
+lldbassert(!m_first_die || m_first_die == m_die_array.front());
+m_first_die = m_die_array.front();

labath wrote:
> xbolva00 wrote:
> > xbolva00 wrote:
> > > @jankratochvil is this correct assert? Our downstream lldb based on lldb 
> > > 7 with our custom targets hits this assert.  If we remove it, we see no 
> > > obvious breakages.
> > cc @labath 
> I agree with Jan. The two dies should be the same. The fact that they aren't 
> probably means there is a bug somewhere. It would be good to know how the two 
> dies differ and what is the input dwarf they are generated from.
A fix of this assertion is now submitted as: D53255


Repository:
  rL LLVM

https://reviews.llvm.org/D46810



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


Re: [Lldb-commits] [PATCH] D46810: Fix DWARFUnit::GetUnitDIEPtrOnly stale pointer

2018-10-14 Thread Jan Kratochvil via lldb-commits
On Thu, 27 Sep 2018 18:21:13 +0200, Greg Clayton via lldb-commits wrote:
> One fix that would work it to make the DWARFDebugInfoEntry* inside the 
> DWARFDie to be mutable and allow it to "fix" itself when a call is made. So 
> the flow would be:
> 
> auto CUDie = cu->GetUnitDIEOnly();
> for (auto child = CUDie.GetFirstChild(); 
> 
> The call to DWARFDie::GetFirstChild() would replace "DWARFDebugInfoEntry 
> *m_die" with the correct version by tracking if m_die is just the unit die 
> only by making "DWARFDebugInfoEntry *m_die" into a llvm::PointerIntPair:
> 
> PointerIntPair< DWARFDebugInfoEntry *, 1> m_die;
> 
> 
> We set the bit to 1 if m_die is just the unit DIE. Then we have an accessor 
> on DWARFDie that can promote m_die to the full version if needed:
> 
> void DWARFDie::PromoteIfNeeded() {
>   if (m_die.getInt()) {
> m_die.setPointer(m_cu->DIEPtr());
> m_die.setInt(false);
>   }
> }

Thanks for the mail but I believe this issue has been already fixed by:
  2/3: Use DWARFBaseDIE as compile-time protection
  https://reviews.llvm.org/D47276

The assertion-regression of this commit is unrelated to stale pointers.
And it has been addressed by now filed:
  Fix: Assertion failed: (!m_first_die || m_first_die == m_die_array.front()), 
function ExtractDIEsRWLocked
  https://reviews.llvm.org/D53255

Or do I miss something?


Thanks,
Jan
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D53255: Fix: Assertion failed: (!m_first_die || m_first_die == m_die_array.front()), function ExtractDIEsRWLocked

2018-10-14 Thread Dávid Bolvanský via Phabricator via lldb-commits
xbolva00 added a comment.

reproducer archive - 404 not found


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D53255



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D53255: Fix: Assertion failed: (!m_first_die || m_first_die == m_die_array.front()), function ExtractDIEsRWLocked

2018-10-14 Thread Jan Kratochvil via Phabricator via lldb-commits
jankratochvil added a comment.

In https://reviews.llvm.org/D53255#1264782, @xbolva00 wrote:

> reproducer archive - 404 not found


Fixed, sorry.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D53255



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D53255: Fix: Assertion failed: (!m_first_die || m_first_die == m_die_array.front()), function ExtractDIEsRWLocked

2018-10-14 Thread Dávid Bolvanský via Phabricator via lldb-commits
xbolva00 added a comment.

In our case (yes, we have some "additional dwarf", we are gonna fix it on our 
side), it crashed with "process launch -s".


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D53255



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits