[Lldb-commits] [lldb] r355388 - Fix embedded Python initialization according to changes in version 3.7

[Tatyana Krasnukha via lldb-commits]

Author: tkrasnukha
Date: Tue Mar  5 03:18:45 2019
New Revision: 355388

URL: http://llvm.org/viewvc/llvm-project?rev=355388&view=rev
Log:
Fix embedded Python initialization according to changes in version 3.7

Differential Revision: https://reviews.llvm.org/D58833

Modified:

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

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=355388&r1=355387&r2=355388&view=diff
==
--- 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp 
(original)
+++ 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp 
Tue Mar  5 03:18:45 2019
@@ -156,7 +156,7 @@ public:
 if (m_was_already_initialized) {
   Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_SCRIPT));
   LLDB_LOGV(log, "Releasing PyGILState. Returning to state = {0}locked",
-m_was_already_initialized == PyGILState_UNLOCKED ? "un" : "");
+m_gil_state == PyGILState_UNLOCKED ? "un" : "");
   PyGILState_Release(m_gil_state);
 } else {
   // We initialized the threads in this function, just unlock the GIL.
@@ -180,6 +180,18 @@ private:
   }
 
   void InitializeThreadsPrivate() {
+// Since Python 3.7 `Py_Initialize` calls `PyEval_InitThreads` inside itself,
+// so there is no way to determine whether the embedded interpreter
+// was already initialized by some external code. `PyEval_ThreadsInitialized`
+// would always return `true` and `PyGILState_Ensure/Release` flow would be
+// executed instead of unlocking GIL with `PyEval_SaveThread`. When
+// an another thread calls `PyGILState_Ensure` it would get stuck in deadlock.
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 7) || (PY_MAJOR_VERSION > 3)
+// The only case we should go further and acquire the GIL: it is unlocked.
+if (PyGILState_Check())
+  return;
+#endif
+
 if (PyEval_ThreadsInitialized()) {
   Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_SCRIPT));
 


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

[Lldb-commits] [PATCH] D58833: Fix embedded Python initialization according to changes in version 3.7

[Phabricator via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL355388: Fix embedded Python initialization according to 
changes in version 3.7 (authored by tkrasnukha, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D58833?vs=188933&id=189290#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58833/new/

https://reviews.llvm.org/D58833

Files:
  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
@@ -156,7 +156,7 @@
 if (m_was_already_initialized) {
   Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_SCRIPT));
   LLDB_LOGV(log, "Releasing PyGILState. Returning to state = {0}locked",
-m_was_already_initialized == PyGILState_UNLOCKED ? "un" : "");
+m_gil_state == PyGILState_UNLOCKED ? "un" : "");
   PyGILState_Release(m_gil_state);
 } else {
   // We initialized the threads in this function, just unlock the GIL.
@@ -180,6 +180,18 @@
   }
 
   void InitializeThreadsPrivate() {
+// Since Python 3.7 `Py_Initialize` calls `PyEval_InitThreads` inside itself,
+// so there is no way to determine whether the embedded interpreter
+// was already initialized by some external code. `PyEval_ThreadsInitialized`
+// would always return `true` and `PyGILState_Ensure/Release` flow would be
+// executed instead of unlocking GIL with `PyEval_SaveThread`. When
+// an another thread calls `PyGILState_Ensure` it would get stuck in deadlock.
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 7) || (PY_MAJOR_VERSION > 3)
+// The only case we should go further and acquire the GIL: it is unlocked.
+if (PyGILState_Check())
+  return;
+#endif
+
 if (PyEval_ThreadsInitialized()) {
   Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_SCRIPT));
 


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
@@ -156,7 +156,7 @@
 if (m_was_already_initialized) {
   Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_SCRIPT));
   LLDB_LOGV(log, "Releasing PyGILState. Returning to state = {0}locked",
-m_was_already_initialized == PyGILState_UNLOCKED ? "un" : "");
+m_gil_state == PyGILState_UNLOCKED ? "un" : "");
   PyGILState_Release(m_gil_state);
 } else {
   // We initialized the threads in this function, just unlock the GIL.
@@ -180,6 +180,18 @@
   }
 
   void InitializeThreadsPrivate() {
+// Since Python 3.7 `Py_Initialize` calls `PyEval_InitThreads` inside itself,
+// so there is no way to determine whether the embedded interpreter
+// was already initialized by some external code. `PyEval_ThreadsInitialized`
+// would always return `true` and `PyGILState_Ensure/Release` flow would be
+// executed instead of unlocking GIL with `PyEval_SaveThread`. When
+// an another thread calls `PyGILState_Ensure` it would get stuck in deadlock.
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 7) || (PY_MAJOR_VERSION > 3)
+// The only case we should go further and acquire the GIL: it is unlocked.
+if (PyGILState_Check())
+  return;
+#endif
+
 if (PyEval_ThreadsInitialized()) {
   Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_SCRIPT));
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r355392 - [lldb] Fix linux host build after r355342

[Alexander Kornienko via lldb-commits]

Author: alexfh
Date: Tue Mar  5 04:05:35 2019
New Revision: 355392

URL: http://llvm.org/viewvc/llvm-project?rev=355392&view=rev
Log:
[lldb] Fix linux host build after r355342

Modified:
lldb/trunk/source/Host/linux/Host.cpp

Modified: lldb/trunk/source/Host/linux/Host.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Host/linux/Host.cpp?rev=355392&r1=355391&r2=355392&view=diff
==
--- lldb/trunk/source/Host/linux/Host.cpp (original)
+++ lldb/trunk/source/Host/linux/Host.cpp Tue Mar  5 04:05:35 2019
@@ -20,6 +20,7 @@
 #include "llvm/Support/ScopedPrinter.h"
 
 #include "lldb/Utility/Log.h"
+#include "lldb/Utility/ProcessInfo.h"
 #include "lldb/Utility/Status.h"
 
 #include "lldb/Host/FileSystem.h"


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

[Lldb-commits] [PATCH] D58946: [SBAPI] Don't check IsValid in constructor

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

The copy constructors and assignment operators are very repetitive. What would 
you say to a function like

  template
  void clone(std::unique_ptr &dest, const std::unique_ptr &src) {
  if (&dest == &src)
return;
  if (src)
dest = llvm::make_unique(*src);
  else
dest.reset();
  }

(and a similar one for shared_ptrs)? Then both copy constructors and assignment 
operators could be just implemented as `clone(m_whatever, rhs.m_whatever);`. 
(Assuming we don't care about pessimizing the self-assignment case this could 
even be `m_whatever = clone(rhs.m_whatever);`)


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58946/new/

https://reviews.llvm.org/D58946



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

[Lldb-commits] [lldb] r355398 - One more UserIDResolver fix

[Pavel Labath via lldb-commits]

Author: labath
Date: Tue Mar  5 04:51:20 2019
New Revision: 355398

URL: http://llvm.org/viewvc/llvm-project?rev=355398&view=rev
Log:
One more UserIDResolver fix

The intention in r355323 has been to implement a no-op resolver in the
HostInfoBase class, which will then be shadowed a an implementation in
the HostInfoPosix class. However, I add the shadowing declaration in
HostInfoPosix.h, and instead had implemented the HostInfoBase function
in HostInfoPosix.cpp. This has lead to undefined symbols on windows, and
a subsequent implementation of a no-op resolver in HostInfoWindows
(r355329).

Since now there is no point on having a no-op resolver in the base
class, I just remove the base declaration altogether, and have
HostInfoPosix implement the (newly-declared) HostInfoPosix version of
that function.

Modified:
lldb/trunk/include/lldb/Host/HostInfoBase.h
lldb/trunk/include/lldb/Host/posix/HostInfoPosix.h
lldb/trunk/source/Host/posix/HostInfoPosix.cpp

Modified: lldb/trunk/include/lldb/Host/HostInfoBase.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Host/HostInfoBase.h?rev=355398&r1=355397&r2=355398&view=diff
==
--- lldb/trunk/include/lldb/Host/HostInfoBase.h (original)
+++ lldb/trunk/include/lldb/Host/HostInfoBase.h Tue Mar  5 04:51:20 2019
@@ -99,8 +99,6 @@ public:
   //---
   static ArchSpec GetAugmentedArchSpec(llvm::StringRef triple);
 
-  static UserIDResolver &GetUserIDResolver();
-
 protected:
   static bool ComputeSharedLibraryDirectory(FileSpec &file_spec);
   static bool ComputeSupportExeDirectory(FileSpec &file_spec);

Modified: lldb/trunk/include/lldb/Host/posix/HostInfoPosix.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Host/posix/HostInfoPosix.h?rev=355398&r1=355397&r2=355398&view=diff
==
--- lldb/trunk/include/lldb/Host/posix/HostInfoPosix.h (original)
+++ lldb/trunk/include/lldb/Host/posix/HostInfoPosix.h Tue Mar  5 04:51:20 2019
@@ -35,6 +35,8 @@ public:
   static bool ComputePathRelativeToLibrary(FileSpec &file_spec,
llvm::StringRef dir);
 
+  static UserIDResolver &GetUserIDResolver();
+
 protected:
   static bool ComputeSupportExeDirectory(FileSpec &file_spec);
   static bool ComputeHeaderDirectory(FileSpec &file_spec);

Modified: lldb/trunk/source/Host/posix/HostInfoPosix.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Host/posix/HostInfoPosix.cpp?rev=355398&r1=355397&r2=355398&view=diff
==
--- lldb/trunk/source/Host/posix/HostInfoPosix.cpp (original)
+++ lldb/trunk/source/Host/posix/HostInfoPosix.cpp Tue Mar  5 04:51:20 2019
@@ -106,7 +106,7 @@ llvm::Optional PosixUserIDR
 
 static llvm::ManagedStatic g_user_id_resolver;
 
-UserIDResolver &HostInfoBase::GetUserIDResolver() {
+UserIDResolver &HostInfoPosix::GetUserIDResolver() {
   return *g_user_id_resolver;
 }
 


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

[Lldb-commits] [PATCH] D55376: Generate LLDB website/documentation from rst with Sphinx

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.
Herald added a subscriber: jdoerfert.
Herald added a project: LLVM.

So, what's the state of this now? The rst files have been committed, but we 
seem to still have the old html files lying around (and AFAICT, 
http://lldb.llvm.org is still serving from those). I am trying make an update 
to the architecture docs, but I am confused as to which version should I be 
editting..


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55376/new/

https://reviews.llvm.org/D55376



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

[Lldb-commits] [PATCH] D58962: Sanity check --max-gdbserver-port

[Jan Kratochvil via Phabricator via lldb-commits]

jankratochvil created this revision.
jankratochvil added a reviewer: LLDB.
jankratochvil added a project: LLDB.
Herald added subscribers: jdoerfert, abidh.

In mail lldb-dev: Remote debugging a docker process 
 user was 
confused by `--min-gdbserver-port` and `--max-gdbserver-port` options being 
ignored.  I think there is even a bug that `--max-gdbserver-port` is upper 
exclusive limit (and not upper inclusive limit appropriate for `max`).
At least this patch should catch such mistake by an error message. The question 
is whether `--max-gdbserver-port` should not be changed to really be `max` and 
not `max+1` but that would break backward compatibility.
Now the mail example does produce:

  error: --min-gdbserver-port (5001) is not lower than --max-gdbserver-port 
(5001)


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D58962

Files:
  lldb/tools/lldb-server/lldb-platform.cpp


Index: lldb/tools/lldb-server/lldb-platform.cpp
===
--- lldb/tools/lldb-server/lldb-platform.cpp
+++ lldb/tools/lldb-server/lldb-platform.cpp
@@ -241,11 +241,11 @@
 return -1;
 
   // Make a port map for a port range that was specified.
-  if (min_gdbserver_port < max_gdbserver_port) {
+  if (min_gdbserver_port && min_gdbserver_port < max_gdbserver_port) {
 for (uint16_t port = min_gdbserver_port; port < max_gdbserver_port; ++port)
   gdbserver_portmap[port] = LLDB_INVALID_PROCESS_ID;
-  } else if (min_gdbserver_port != max_gdbserver_port) {
-fprintf(stderr, "error: --min-gdbserver-port (%u) is greater than "
+  } else if (min_gdbserver_port || max_gdbserver_port) {
+fprintf(stderr, "error: --min-gdbserver-port (%u) is not lower than "
 "--max-gdbserver-port (%u)\n",
 min_gdbserver_port, max_gdbserver_port);
 option_error = 3;


Index: lldb/tools/lldb-server/lldb-platform.cpp
===
--- lldb/tools/lldb-server/lldb-platform.cpp
+++ lldb/tools/lldb-server/lldb-platform.cpp
@@ -241,11 +241,11 @@
 return -1;
 
   // Make a port map for a port range that was specified.
-  if (min_gdbserver_port < max_gdbserver_port) {
+  if (min_gdbserver_port && min_gdbserver_port < max_gdbserver_port) {
 for (uint16_t port = min_gdbserver_port; port < max_gdbserver_port; ++port)
   gdbserver_portmap[port] = LLDB_INVALID_PROCESS_ID;
-  } else if (min_gdbserver_port != max_gdbserver_port) {
-fprintf(stderr, "error: --min-gdbserver-port (%u) is greater than "
+  } else if (min_gdbserver_port || max_gdbserver_port) {
+fprintf(stderr, "error: --min-gdbserver-port (%u) is not lower than "
 "--max-gdbserver-port (%u)\n",
 min_gdbserver_port, max_gdbserver_port);
 option_error = 3;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D58930: Add XCOFF triple object format type for AIX

[Andrew Paprocki via Phabricator via lldb-commits]

apaprocki added inline comments.



Comment at: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp:2079
+  if (log)
+log->Printf("sorry: unimplemented for XCOFF");
+  return false;

No need to be `sorry:` :) This should probably just say `error: XCOFF is 
unimplemented` to be more direct in case anything is expecting "error:" in the 
output.



Comment at: llvm/lib/Support/Triple.cpp:537
   return StringSwitch(EnvironmentName)
+// FIXME: We have to put XCOFF before COFF;
+// perhaps an order-independent pattern matching is desired?

hubert.reinterpretcast wrote:
> If the conclusion is that checking XCOFF before COFF is fine, then we should 
> remove the FIXME and just leave a normal comment.
Agreed, existing code seems fine as long as there is a comment explaining that 
`xcoff` must come before `coff` in case it isn't obvious at a quick glance.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58930/new/

https://reviews.llvm.org/D58930



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

[Lldb-commits] [PATCH] D58962: Sanity check --max-gdbserver-port

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

Perhaps it would be nice to write a test-case for that. It should be as simple 
as running `not lldb-server --whatever` and FileChecking the output.


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58962/new/

https://reviews.llvm.org/D58962



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

[Lldb-commits] [PATCH] D57689: Adds property to force enabling of GDB JIT loader for MacOS

[Yury Delendik via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL355402: Adds property to force enabling of GDB JIT loader 
for MacOS (authored by yurydelendik, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D57689?vs=189244&id=189311#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57689/new/

https://reviews.llvm.org/D57689

Files:
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/jitloader_gdb/Makefile
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/jitloader_gdb/TestJITLoaderGDB.py
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/jitloader_gdb/simple.c
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/jitloader_gdb/simple.mk
  lldb/trunk/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp

Index: lldb/trunk/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp
===
--- lldb/trunk/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp
+++ lldb/trunk/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp
@@ -59,11 +59,27 @@
 
 namespace {
 
+enum EnableJITLoaderGDB {
+  eEnableJITLoaderGDBDefault,
+  eEnableJITLoaderGDBOn,
+  eEnableJITLoaderGDBOff,
+};
+
+static constexpr OptionEnumValueElement g_enable_jit_loader_gdb_enumerators[] = {
+{eEnableJITLoaderGDBDefault, "default", "Enable JIT compilation interface "
+ "for all platforms except macOS"},
+{eEnableJITLoaderGDBOn, "on", "Enable JIT compilation interface"},
+{eEnableJITLoaderGDBOff, "off", "Disable JIT compilation interface"}
+ };
+
 static constexpr PropertyDefinition g_properties[] = {
-{"enable-jit-breakpoint", OptionValue::eTypeBoolean, true, true, nullptr,
- {}, "Enable breakpoint on __jit_debug_register_code."}};
+{"enable", OptionValue::eTypeEnum, true,
+ eEnableJITLoaderGDBDefault, nullptr,
+ OptionEnumValues(g_enable_jit_loader_gdb_enumerators),
+ "Enable GDB's JIT compilation interface (default: enabled on "
+ "all platforms except macOS)"}};
 
-enum { ePropertyEnableJITBreakpoint };
+enum { ePropertyEnable, ePropertyEnableJITBreakpoint };
 
 class PluginProperties : public Properties {
 public:
@@ -76,10 +92,10 @@
 m_collection_sp->Initialize(g_properties);
   }
 
-  bool GetEnableJITBreakpoint() const {
-return m_collection_sp->GetPropertyAtIndexAsBoolean(
-nullptr, ePropertyEnableJITBreakpoint,
-g_properties[ePropertyEnableJITBreakpoint].default_uint_value != 0);
+  EnableJITLoaderGDB GetEnable() const {
+return (EnableJITLoaderGDB)m_collection_sp->GetPropertyAtIndexAsEnumeration(
+nullptr, ePropertyEnable,
+g_properties[ePropertyEnable].default_uint_value);
   }
 };
 
@@ -165,9 +181,6 @@
 // Setup the JIT Breakpoint
 //--
 void JITLoaderGDB::SetJITBreakpoint(lldb_private::ModuleList &module_list) {
-  if (!GetGlobalPluginProperties()->GetEnableJITBreakpoint())
-return;
-
   if (DidSetJITBreakpoint())
 return;
 
@@ -402,8 +415,20 @@
 
 JITLoaderSP JITLoaderGDB::CreateInstance(Process *process, bool force) {
   JITLoaderSP jit_loader_sp;
-  ArchSpec arch(process->GetTarget().GetArchitecture());
-  if (arch.GetTriple().getVendor() != llvm::Triple::Apple)
+  bool enable;
+  switch (GetGlobalPluginProperties()->GetEnable()) {
+case EnableJITLoaderGDB::eEnableJITLoaderGDBOn:
+  enable = true;
+  break;
+case EnableJITLoaderGDB::eEnableJITLoaderGDBOff:
+  enable = false;
+  break;
+case EnableJITLoaderGDB::eEnableJITLoaderGDBDefault:
+  ArchSpec arch(process->GetTarget().GetArchitecture());
+  enable = arch.GetTriple().getVendor() != llvm::Triple::Apple;
+  break;
+  }
+  if (enable)
 jit_loader_sp = std::make_shared(process);
   return jit_loader_sp;
 }
Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/jitloader_gdb/TestJITLoaderGDB.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/jitloader_gdb/TestJITLoaderGDB.py
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/jitloader_gdb/TestJITLoaderGDB.py
@@ -10,6 +10,7 @@
 from lldbsuite.test.lldbtest import *
 import re
 
+file_index = 0
 
 class JITLoaderGDBTestCase(TestBase):
 
@@ -38,3 +39,80 @@
 
 self.assertEqual(process.GetState(), lldb.eStateExited)
 self.assertEqual(process.GetExitStatus(), 0)
+
+def gen_log_file(self):
+global file_index
+++file_index
+logfile = os.path.join(
+self.getBuildDir(),
+"jitintgdb-" + self.getArchitecture() + "-" +
+str(file_index) + ".txt")
+
+def cleanup():
+if os.path.exists(logfile):
+os.unlink(logfile)
+self.addTearDownHook(cleanup)
+return logfile
+
+def test_jit_int_default(self

[Lldb-commits] [lldb] r355406 - Revert "Fix embedded Python initialization according to changes in version 3.7"

[Tatyana Krasnukha via lldb-commits]

Author: tkrasnukha
Date: Tue Mar  5 07:27:33 2019
New Revision: 355406

URL: http://llvm.org/viewvc/llvm-project?rev=355406&view=rev
Log:
Revert "Fix embedded Python initialization according to changes in version 3.7"

Testsuite hangs on Windows likely due to these changes.

Modified:

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

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=355406&r1=355405&r2=355406&view=diff
==
--- 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp 
(original)
+++ 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp 
Tue Mar  5 07:27:33 2019
@@ -156,7 +156,7 @@ public:
 if (m_was_already_initialized) {
   Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_SCRIPT));
   LLDB_LOGV(log, "Releasing PyGILState. Returning to state = {0}locked",
-m_gil_state == PyGILState_UNLOCKED ? "un" : "");
+m_was_already_initialized == PyGILState_UNLOCKED ? "un" : "");
   PyGILState_Release(m_gil_state);
 } else {
   // We initialized the threads in this function, just unlock the GIL.
@@ -180,18 +180,6 @@ private:
   }
 
   void InitializeThreadsPrivate() {
-// Since Python 3.7 `Py_Initialize` calls `PyEval_InitThreads` inside itself,
-// so there is no way to determine whether the embedded interpreter
-// was already initialized by some external code. `PyEval_ThreadsInitialized`
-// would always return `true` and `PyGILState_Ensure/Release` flow would be
-// executed instead of unlocking GIL with `PyEval_SaveThread`. When
-// an another thread calls `PyGILState_Ensure` it would get stuck in deadlock.
-#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 7) || (PY_MAJOR_VERSION > 3)
-// The only case we should go further and acquire the GIL: it is unlocked.
-if (PyGILState_Check())
-  return;
-#endif
-
 if (PyEval_ThreadsInitialized()) {
   Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_SCRIPT));
 


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

[Lldb-commits] [PATCH] D58946: [SBAPI] Don't check IsValid in constructor

[Greg Clayton via Phabricator via lldb-commits]

clayborg accepted this revision.
clayborg added a comment.
This revision is now accepted and ready to land.

lgtm


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58946/new/

https://reviews.llvm.org/D58946



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

Re: [Lldb-commits] [lldb] r355406 - Revert "Fix embedded Python initialization according to changes in version 3.7"

[Davide Italiano via lldb-commits]

This is unfortunate, because I think it's the correct path forward.
Stella, do you know why this is failing on Windows?

Thanks,

--
Davide


On Tue, Mar 5, 2019 at 7:26 AM Tatyana Krasnukha via lldb-commits
 wrote:
>
> Author: tkrasnukha
> Date: Tue Mar  5 07:27:33 2019
> New Revision: 355406
>
> URL: http://llvm.org/viewvc/llvm-project?rev=355406&view=rev
> Log:
> Revert "Fix embedded Python initialization according to changes in version 
> 3.7"
>
> Testsuite hangs on Windows likely due to these changes.
>
> Modified:
> 
> lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
>
> 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=355406&r1=355405&r2=355406&view=diff
> ==
> --- 
> lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
>  (original)
> +++ 
> lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
>  Tue Mar  5 07:27:33 2019
> @@ -156,7 +156,7 @@ public:
>  if (m_was_already_initialized) {
>Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_SCRIPT));
>LLDB_LOGV(log, "Releasing PyGILState. Returning to state = {0}locked",
> -m_gil_state == PyGILState_UNLOCKED ? "un" : "");
> +m_was_already_initialized == PyGILState_UNLOCKED ? "un" : 
> "");
>PyGILState_Release(m_gil_state);
>  } else {
>// We initialized the threads in this function, just unlock the GIL.
> @@ -180,18 +180,6 @@ private:
>}
>
>void InitializeThreadsPrivate() {
> -// Since Python 3.7 `Py_Initialize` calls `PyEval_InitThreads` inside itself,
> -// so there is no way to determine whether the embedded interpreter
> -// was already initialized by some external code. `PyEval_ThreadsInitialized`
> -// would always return `true` and `PyGILState_Ensure/Release` flow would be
> -// executed instead of unlocking GIL with `PyEval_SaveThread`. When
> -// an another thread calls `PyGILState_Ensure` it would get stuck in 
> deadlock.
> -#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 7) || (PY_MAJOR_VERSION > 
> 3)
> -// The only case we should go further and acquire the GIL: it is unlocked.
> -if (PyGILState_Check())
> -  return;
> -#endif
> -
>  if (PyEval_ThreadsInitialized()) {
>Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_SCRIPT));
>
>
>
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r355406 - Revert "Fix embedded Python initialization according to changes in version 3.7"

[Davide Italiano via lldb-commits]

I'm also at a loss trying to understand how this particular change
could've caused the tests to hang.

  __VSCMD_PREINIT_PATH=C:\Program Files (x86)\Microsoft Visual
Studio\Shared\Python36_64\Scripts\;C:\Program Files (x86)\Microsoft
Visual 
Studio\Shared\Python36_64\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program
Files\dotnet\;C:\Program Files (x86)\GtkSharp\2.12\bin;C:\Program
Files\CMake\bin;C:\Program Files (x86)\swigwin-3.0.12;C:\Program Files
(x86)\GetGnuWin32\gnuwin32\bin;c:\Python27\Scripts\;C:\Program Files
(x86)\Ninja;C:\Program Files\Git\cmd;C:\Program
Files\TortoiseSVN\bin;C:\Users\buildslave\AppData\Local\Microsoft\WindowsApps;C:\Python27\lib\site-packages\pywin32_system32;C:\Python27\lib\site-packages\pywin32_system32
 using PTY: False


This is what I see on the Windows bot, so, I expect that it runs
Python 3.6, but the whole fix is conditional to PY_MAJOR_VERSION == 3
&& PY_MINOR_VERSION >= 7.

On Tue, Mar 5, 2019 at 7:53 AM Davide Italiano  wrote:
>
> This is unfortunate, because I think it's the correct path forward.
> Stella, do you know why this is failing on Windows?
>
> Thanks,
>
> --
> Davide
>
>
> On Tue, Mar 5, 2019 at 7:26 AM Tatyana Krasnukha via lldb-commits
>  wrote:
> >
> > Author: tkrasnukha
> > Date: Tue Mar  5 07:27:33 2019
> > New Revision: 355406
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=355406&view=rev
> > Log:
> > Revert "Fix embedded Python initialization according to changes in version 
> > 3.7"
> >
> > Testsuite hangs on Windows likely due to these changes.
> >
> > Modified:
> > 
> > lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
> >
> > 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=355406&r1=355405&r2=355406&view=diff
> > ==
> > --- 
> > lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
> >  (original)
> > +++ 
> > lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
> >  Tue Mar  5 07:27:33 2019
> > @@ -156,7 +156,7 @@ public:
> >  if (m_was_already_initialized) {
> >Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_SCRIPT));
> >LLDB_LOGV(log, "Releasing PyGILState. Returning to state = 
> > {0}locked",
> > -m_gil_state == PyGILState_UNLOCKED ? "un" : "");
> > +m_was_already_initialized == PyGILState_UNLOCKED ? "un" : 
> > "");
> >PyGILState_Release(m_gil_state);
> >  } else {
> >// We initialized the threads in this function, just unlock the GIL.
> > @@ -180,18 +180,6 @@ private:
> >}
> >
> >void InitializeThreadsPrivate() {
> > -// Since Python 3.7 `Py_Initialize` calls `PyEval_InitThreads` inside 
> > itself,
> > -// so there is no way to determine whether the embedded interpreter
> > -// was already initialized by some external code. 
> > `PyEval_ThreadsInitialized`
> > -// would always return `true` and `PyGILState_Ensure/Release` flow would be
> > -// executed instead of unlocking GIL with `PyEval_SaveThread`. When
> > -// an another thread calls `PyGILState_Ensure` it would get stuck in 
> > deadlock.
> > -#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 7) || (PY_MAJOR_VERSION 
> > > 3)
> > -// The only case we should go further and acquire the GIL: it is unlocked.
> > -if (PyGILState_Check())
> > -  return;
> > -#endif
> > -
> >  if (PyEval_ThreadsInitialized()) {
> >Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_SCRIPT));
> >
> >
> >
> > ___
> > lldb-commits mailing list
> > lldb-commits@lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D58970: Move RangeMap.h into Utility

[Pavel Labath via Phabricator via lldb-commits]

labath created this revision.
labath added reviewers: zturner, jingham, JDevlieghere, clayborg.
Herald added subscribers: MaskRay, arichardson, javed.absar, mgorny, emaste.
Herald added a reviewer: espindola.

This file implements some general purpose data structures, and so it
belongs to the Utility module.


https://reviews.llvm.org/D58970

Files:
  include/lldb/Core/RangeMap.h
  include/lldb/Core/dwarf.h
  include/lldb/Symbol/ArmUnwindInfo.h
  include/lldb/Symbol/Block.h
  include/lldb/Symbol/CompactUnwindInfo.h
  include/lldb/Symbol/DWARFCallFrameInfo.h
  include/lldb/Symbol/LineTable.h
  include/lldb/Symbol/Symtab.h
  include/lldb/Symbol/Variable.h
  include/lldb/Target/Memory.h
  include/lldb/Target/MemoryRegionInfo.h
  include/lldb/Utility/RangeMap.h
  source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
  source/Plugins/ObjectFile/JIT/ObjectFileJIT.cpp
  source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
  source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.h
  source/Plugins/SymbolFile/DWARF/DWARFDebugAranges.h
  source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
  source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
  source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h
  source/Target/Memory.cpp
  unittests/Core/CMakeLists.txt
  unittests/Core/RangeMapTest.cpp
  unittests/Core/RangeTest.cpp
  unittests/Utility/CMakeLists.txt
  unittests/Utility/RangeMapTest.cpp
  unittests/Utility/RangeTest.cpp

Index: unittests/Utility/RangeTest.cpp
===
--- unittests/Utility/RangeTest.cpp
+++ unittests/Utility/RangeTest.cpp
@@ -6,7 +6,7 @@
 //
 //===--===//
 
-#include "lldb/Core/RangeMap.h"
+#include "lldb/Utility/RangeMap.h"
 
 #include 
 #include 
Index: unittests/Utility/RangeMapTest.cpp
===
--- unittests/Utility/RangeMapTest.cpp
+++ unittests/Utility/RangeMapTest.cpp
@@ -6,7 +6,7 @@
 //
 //===--===//
 
-#include "lldb/Core/RangeMap.h"
+#include "lldb/Utility/RangeMap.h"
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
 
Index: unittests/Utility/CMakeLists.txt
===
--- unittests/Utility/CMakeLists.txt
+++ unittests/Utility/CMakeLists.txt
@@ -19,6 +19,8 @@
   NameMatchesTest.cpp
   PredicateTest.cpp
   ProcessInfoTest.cpp
+  RangeMapTest.cpp
+  RangeTest.cpp
   RegisterValueTest.cpp
   ReproducerTest.cpp
   ReproducerInstrumentationTest.cpp
Index: unittests/Core/CMakeLists.txt
===
--- unittests/Core/CMakeLists.txt
+++ unittests/Core/CMakeLists.txt
@@ -1,7 +1,5 @@
 add_lldb_unittest(LLDBCoreTests
   MangledTest.cpp
-  RangeMapTest.cpp
-  RangeTest.cpp
   RichManglingContextTest.cpp
   StreamCallbackTest.cpp
 
Index: source/Target/Memory.cpp
===
--- source/Target/Memory.cpp
+++ source/Target/Memory.cpp
@@ -8,10 +8,10 @@
 
 #include "lldb/Target/Memory.h"
 
-#include "lldb/Core/RangeMap.h"
 #include "lldb/Target/Process.h"
 #include "lldb/Utility/DataBufferHeap.h"
 #include "lldb/Utility/Log.h"
+#include "lldb/Utility/RangeMap.h"
 #include "lldb/Utility/State.h"
 
 #include 
Index: source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h
===
--- source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h
+++ source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h
@@ -13,8 +13,8 @@
 #include 
 #include 
 
-#include "lldb/Core/RangeMap.h"
 #include "lldb/Symbol/SymbolFile.h"
+#include "lldb/Utility/RangeMap.h"
 #include "llvm/Support/Chrono.h"
 
 #include "UniqueDWARFASTType.h"
Index: source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
===
--- source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
+++ source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
@@ -12,9 +12,9 @@
 #include "lldb/Core/Module.h"
 #include "lldb/Core/ModuleList.h"
 #include "lldb/Core/PluginManager.h"
-#include "lldb/Core/RangeMap.h"
 #include "lldb/Core/Section.h"
 #include "lldb/Host/FileSystem.h"
+#include "lldb/Utility/RangeMap.h"
 #include "lldb/Utility/RegularExpression.h"
 #include "lldb/Utility/Timer.h"
 
Index: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
===
--- source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
+++ source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
@@ -21,7 +21,6 @@
 
 #include "lldb/Utility/Flags.h"
 
-#include "lldb/Core/RangeMap.h"
 #include "lldb/Core/UniqueCStringMap.h"
 #include "lldb/Core/dwarf.h"
 #include "lldb/Expression/DWARFExpression.h"
@@ -29,6 +28,7 @@
 #include "lldb/Symbol/SymbolContext.h"
 #include "lldb/Symbol/SymbolFile.h"
 #inc

Re: [Lldb-commits] [PATCH] D58946: [SBAPI] Don't check IsValid in constructor

[Jonas Devlieghere via lldb-commits]

Sounds good, I’ll make this change before landing, unless you have further
comments?

On Tue, Mar 5, 2019 at 4:29 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:

> labath added a comment.
>
> The copy constructors and assignment operators are very repetitive. What
> would you say to a function like
>
>   template
>   void clone(std::unique_ptr &dest, const std::unique_ptr &src) {
>   if (&dest == &src)
> return;
>   if (src)
> dest = llvm::make_unique(*src);
>   else
> dest.reset();
>   }
>
> (and a similar one for shared_ptrs)? Then both copy constructors and
> assignment operators could be just implemented as `clone(m_whatever,
> rhs.m_whatever);`. (Assuming we don't care about pessimizing the
> self-assignment case this could even be `m_whatever =
> clone(rhs.m_whatever);`)
>
>
> Repository:
>   rLLDB LLDB
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D58946/new/
>
> https://reviews.llvm.org/D58946
>
>
>
> --
Sent from my iPhone
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D58971: Move MemoryRegionInfo into the Utility module

[Pavel Labath via Phabricator via lldb-commits]

labath created this revision.
labath added reviewers: zturner, jingham, JDevlieghere, clayborg.
Herald added a subscriber: mgorny.
labath added a parent revision: D58970: Move RangeMap.h into Utility.

MemoryRegionInfo describes the region of memory in a process, but this
does not have to be the liblldb's notion of a process (in fact, this
class is already used in lldb-server, which has a different hierarchy of
process-related classes).

So a better place for it would be in the Utility module (next to
RegisterValue, State and similar). We might also consider creating a new
module for classes like this, because we currently have a number of
classes which can be described as "properties of a process" in the
Utility module.


https://reviews.llvm.org/D58971

Files:
  include/lldb/Target/MemoryRegionInfo.h
  include/lldb/Utility/MemoryRegionInfo.h
  source/API/SBMemoryRegionInfo.cpp
  source/API/SBMemoryRegionInfoList.cpp
  source/API/SBProcess.cpp
  source/Commands/CommandObjectMemory.cpp
  source/Core/DynamicLoader.cpp
  source/Expression/IRMemoryMap.cpp
  source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp
  source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
  source/Plugins/Process/Darwin/NativeProcessDarwin.h
  source/Plugins/Process/Linux/NativeProcessLinux.h
  source/Plugins/Process/NetBSD/NativeProcessNetBSD.h
  source/Plugins/Process/Utility/LinuxProcMaps.cpp
  source/Plugins/Process/Windows/Common/ProcessWindows.cpp
  source/Plugins/Process/elf-core/ProcessElfCore.cpp
  source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
  source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
  source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  source/Plugins/Process/mach-core/ProcessMachCore.cpp
  source/Plugins/Process/minidump/MinidumpParser.h
  source/Plugins/Process/minidump/ProcessMinidump.cpp
  source/Target/Process.cpp
  unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
  unittests/Process/minidump/MinidumpParserTest.cpp
  unittests/Target/CMakeLists.txt
  unittests/Target/MemoryRegionInfoTest.cpp
  unittests/Utility/CMakeLists.txt
  unittests/Utility/MemoryRegionInfoTest.cpp

Index: unittests/Utility/MemoryRegionInfoTest.cpp
===
--- unittests/Utility/MemoryRegionInfoTest.cpp
+++ unittests/Utility/MemoryRegionInfoTest.cpp
@@ -6,7 +6,7 @@
 //
 //===--===//
 
-#include "lldb/Target/MemoryRegionInfo.h"
+#include "lldb/Utility/MemoryRegionInfo.h"
 #include "llvm/Support/FormatVariadic.h"
 #include "gtest/gtest.h"
 
@@ -15,5 +15,6 @@
 TEST(MemoryRegionInfoTest, Formatv) {
   EXPECT_EQ("yes", llvm::formatv("{0}", MemoryRegionInfo::eYes).str());
   EXPECT_EQ("no", llvm::formatv("{0}", MemoryRegionInfo::eNo).str());
-  EXPECT_EQ("don't know", llvm::formatv("{0}", MemoryRegionInfo::eDontKnow).str());
+  EXPECT_EQ("don't know",
+llvm::formatv("{0}", MemoryRegionInfo::eDontKnow).str());
 }
Index: unittests/Utility/CMakeLists.txt
===
--- unittests/Utility/CMakeLists.txt
+++ unittests/Utility/CMakeLists.txt
@@ -16,6 +16,7 @@
   JSONTest.cpp
   ListenerTest.cpp
   LogTest.cpp
+  MemoryRegionInfoTest.cpp
   NameMatchesTest.cpp
   PredicateTest.cpp
   ProcessInfoTest.cpp
Index: unittests/Target/CMakeLists.txt
===
--- unittests/Target/CMakeLists.txt
+++ unittests/Target/CMakeLists.txt
@@ -1,5 +1,4 @@
 add_lldb_unittest(TargetTests
-  MemoryRegionInfoTest.cpp
   ModuleCacheTest.cpp
   PathMappingListTest.cpp
   ProcessInstanceInfoTest.cpp
Index: unittests/Process/minidump/MinidumpParserTest.cpp
===
--- unittests/Process/minidump/MinidumpParserTest.cpp
+++ unittests/Process/minidump/MinidumpParserTest.cpp
@@ -12,7 +12,7 @@
 #include "Plugins/Process/minidump/RegisterContextMinidump_x86_64.h"
 #include "TestingSupport/TestUtilities.h"
 #include "lldb/Host/FileSystem.h"
-#include "lldb/Target/MemoryRegionInfo.h"
+#include "lldb/Utility/MemoryRegionInfo.h"
 #include "lldb/Utility/ArchSpec.h"
 #include "lldb/Utility/DataExtractor.h"
 #include "lldb/Utility/FileSpec.h"
Index: unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
===
--- unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
+++ unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
@@ -9,8 +9,8 @@
 #include "GDBRemoteTestUtils.h"
 #include "lldb/Core/ModuleSpec.h"
 #include "lldb/Host/XML.h"
-#include "lldb/Target/MemoryRegionInfo.h"
 #include "lldb/Utility/DataBuffer.h"
+#include "lldb/Utility/MemoryRegionInfo.h"
 #include "lldb/Utility/StructuredData.h"
 #include "lldb/Utility/TraceOptions.h"
 #include "lldb/lldb-enumerations.h"
Index: source/Target/Process.cpp
===

[Lldb-commits] [PATCH] D58972: Introduce the "Formats" module and move LinuxProcMaps parser to it

[Pavel Labath via Phabricator via lldb-commits]

labath created this revision.
labath added reviewers: zturner, jingham, JDevlieghere, clayborg, teemperor.
Herald added subscribers: arphaman, aprantl, mgorny.

This patch introduces a "Formats" library, whose goal is to contain
serialization and deserialization code for various textual and binary
formats that lldb needs to work with. The motivation is to enable
building various tools on top of this, which do not need to depend on
the entire lldb codebase. (I have written a slightly more elaborate
version of this is given in the lldb architecture docs, which I update
to mention the new library).

LinuxProcMaps is just the beginning here. As the next immediate step I
plan to move the Minidump parsing code (currently burried in
source/Plugins/Process/minidump) here as well, but in the future I think
this library could contain the gdb-remote protocol code (currently in
source/Plugins/Process/gdb-remote) and the debug info protocol code
(currently in Zach's head).


https://reviews.llvm.org/D58972

Files:
  docs/use/architecture.rst
  include/lldb/Formats/LinuxProcMaps.h
  include/lldb/module.modulemap
  source/CMakeLists.txt
  source/Formats/CMakeLists.txt
  source/Formats/LinuxProcMaps.cpp
  source/Plugins/Process/Linux/CMakeLists.txt
  source/Plugins/Process/Linux/NativeProcessLinux.cpp
  source/Plugins/Process/Utility/CMakeLists.txt
  source/Plugins/Process/Utility/LinuxProcMaps.cpp
  source/Plugins/Process/Utility/LinuxProcMaps.h
  source/Plugins/Process/minidump/CMakeLists.txt
  source/Plugins/Process/minidump/MinidumpParser.cpp
  unittests/CMakeLists.txt
  unittests/Formats/CMakeLists.txt
  unittests/Formats/LinuxProcMapsTest.cpp
  www/architecture/index.html

Index: www/architecture/index.html
===
--- www/architecture/index.html
+++ www/architecture/index.html
@@ -38,6 +38,7 @@
   	Core
   	DataFormatters
	Expression
+   	Formats
	Host
	Interpreter
	Symbol
@@ -186,6 +187,32 @@
 
 
 			
+			
+			
+Formats
+
+   
+   The Formats module contains the code for
+   handling various types of data formats that
+   LLDB needs to work with. This includes
+   serialization and deserialization code for
+   all kinds of textual and binary formats,
+   ranging from the contents of the linux
+   /proc/PID/maps file, to windows minidump
+   files. The goal of this library is to present
+   the data in an easily accessible fashion.
+   However, it does not connect this data to
+   higher level lldb concepts (Targets, Modules,
+   ...) -- that's the job of individual plugins.
+   The goal of this is so that another
+   application (or lldb-server) can use the
+   (de)serialization code from this library
+   without depending on the lldb object model,
+   or being constrained by it.
+   
+
+
+			
 			
 			
 			  Host
Index: unittests/Formats/LinuxProcMapsTest.cpp
===
--- /dev/null
+++ unittests/Formats/LinuxProcMapsTest.cpp
@@ -0,0 +1,32 @@
+//===-- LinuxProcMapsTest.cpp ---*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/Formats/LinuxProcMaps.h"
+#include "lldb/Utility/MemoryRegionInfo.h"
+#include "lldb/Utility/Status.h"
+#include "gtest/gtest.h"
+
+using namespace lldb_private;
+
+TEST(LinuxProcMaps, ParseLinuxMapRegions) {
+  std::vector Infos;
+  ParseLinuxMapRegions("557bdd004000-557bdd0bc000 r-xp  fd:01 3012381  "
+   "  /bin/bash",
+   [&](const MemoryRegionInfo &Info, const Status &ST) {
+ EXPECT_TRUE(ST.Success());
+ Infos.push_back(Info);
+ return true;
+   });
+  ASSERT_EQ(1u, Infos.size());
+  EXPECT_EQ(0x557bdd004000u, Infos[0].GetRange().GetRangeBase());
+  EXPECT_EQ(0x557bdd0bc000u, Infos[0].GetRange().GetRangeEnd());
+  EXPECT_EQ(MemoryRegionInfo::eYes, Infos[0].GetReadable());
+  EXPECT_EQ(MemoryRegionInfo::eNo, Infos[0].GetWrita

[Lldb-commits] [PATCH] D58973: Move the minidump parser into the Formats module

[Pavel Labath via Phabricator via lldb-commits]

labath created this revision.
labath added reviewers: zturner, lemo, clayborg, JDevlieghere.
Herald added subscribers: javed.absar, mgorny.

the parser was already independent from the lldb Process classes, but it
was living in source/Plugins/Process/minidump, because we did not have a
good place to put it. Now that we have the new Formats module, it can be
moved there. This enables writing new interesting tools (such as
yaml2core), which process minidump files independently of lldb.


https://reviews.llvm.org/D58973

Files:
  include/lldb/Formats/MinidumpParser.h
  include/lldb/Formats/MinidumpTypes.h
  source/Formats/CMakeLists.txt
  source/Formats/MinidumpParser.cpp
  source/Formats/MinidumpTypes.cpp
  source/Plugins/Process/minidump/CMakeLists.txt
  source/Plugins/Process/minidump/MinidumpParser.cpp
  source/Plugins/Process/minidump/MinidumpParser.h
  source/Plugins/Process/minidump/MinidumpTypes.cpp
  source/Plugins/Process/minidump/MinidumpTypes.h
  source/Plugins/Process/minidump/NtStructures.h
  source/Plugins/Process/minidump/ProcessMinidump.h
  source/Plugins/Process/minidump/RegisterContextMinidump_ARM.h
  source/Plugins/Process/minidump/RegisterContextMinidump_ARM64.h
  source/Plugins/Process/minidump/RegisterContextMinidump_x86_32.cpp
  source/Plugins/Process/minidump/RegisterContextMinidump_x86_32.h
  source/Plugins/Process/minidump/RegisterContextMinidump_x86_64.cpp
  source/Plugins/Process/minidump/RegisterContextMinidump_x86_64.h
  source/Plugins/Process/minidump/ThreadMinidump.h
  unittests/Formats/CMakeLists.txt
  unittests/Formats/Inputs/bad_duplicate_streams.dmp
  unittests/Formats/Inputs/bad_overlapping_streams.dmp
  unittests/Formats/Inputs/dump-content.dmp
  unittests/Formats/Inputs/fizzbuzz_no_heap.dmp
  unittests/Formats/Inputs/fizzbuzz_wow64.dmp
  unittests/Formats/Inputs/linux-i386.dmp
  unittests/Formats/Inputs/linux-x86_64.cpp
  unittests/Formats/Inputs/linux-x86_64.dmp
  unittests/Formats/Inputs/linux-x86_64_not_crashed.dmp
  unittests/Formats/Inputs/memory-list-not-padded.dmp
  unittests/Formats/Inputs/memory-list-padded.dmp
  unittests/Formats/Inputs/module-list-not-padded.dmp
  unittests/Formats/Inputs/module-list-padded.dmp
  unittests/Formats/Inputs/modules-dup-min-addr.dmp
  unittests/Formats/Inputs/modules-order.dmp
  unittests/Formats/Inputs/regions-linux-map.dmp
  unittests/Formats/Inputs/regions-memlist.dmp
  unittests/Formats/Inputs/regions-memlist64.dmp
  unittests/Formats/Inputs/thread-list-not-padded.dmp
  unittests/Formats/Inputs/thread-list-padded.dmp
  unittests/Formats/MinidumpParserTest.cpp
  unittests/Process/minidump/CMakeLists.txt
  unittests/Process/minidump/Inputs/bad_duplicate_streams.dmp
  unittests/Process/minidump/Inputs/bad_overlapping_streams.dmp
  unittests/Process/minidump/Inputs/dump-content.dmp
  unittests/Process/minidump/Inputs/fizzbuzz_no_heap.dmp
  unittests/Process/minidump/Inputs/fizzbuzz_wow64.dmp
  unittests/Process/minidump/Inputs/linux-i386.dmp
  unittests/Process/minidump/Inputs/linux-x86_64.cpp
  unittests/Process/minidump/Inputs/linux-x86_64.dmp
  unittests/Process/minidump/Inputs/linux-x86_64_not_crashed.dmp
  unittests/Process/minidump/Inputs/memory-list-not-padded.dmp
  unittests/Process/minidump/Inputs/memory-list-padded.dmp
  unittests/Process/minidump/Inputs/module-list-not-padded.dmp
  unittests/Process/minidump/Inputs/module-list-padded.dmp
  unittests/Process/minidump/Inputs/modules-dup-min-addr.dmp
  unittests/Process/minidump/Inputs/modules-order.dmp
  unittests/Process/minidump/Inputs/regions-linux-map.dmp
  unittests/Process/minidump/Inputs/regions-memlist.dmp
  unittests/Process/minidump/Inputs/regions-memlist64.dmp
  unittests/Process/minidump/Inputs/thread-list-not-padded.dmp
  unittests/Process/minidump/Inputs/thread-list-padded.dmp
  unittests/Process/minidump/MinidumpParserTest.cpp
  unittests/Process/minidump/RegisterContextMinidumpTest.cpp

Index: unittests/Process/minidump/RegisterContextMinidumpTest.cpp
===
--- unittests/Process/minidump/RegisterContextMinidumpTest.cpp
+++ unittests/Process/minidump/RegisterContextMinidumpTest.cpp
@@ -10,6 +10,7 @@
 #include "Plugins/Process/Utility/RegisterContextLinux_x86_64.h"
 #include "Plugins/Process/minidump/RegisterContextMinidump_x86_32.h"
 #include "Plugins/Process/minidump/RegisterContextMinidump_x86_64.h"
+#include "lldb/Formats/MinidumpTypes.h"
 #include "lldb/Utility/DataBuffer.h"
 #include "gtest/gtest.h"
 
Index: unittests/Process/minidump/CMakeLists.txt
===
--- unittests/Process/minidump/CMakeLists.txt
+++ unittests/Process/minidump/CMakeLists.txt
@@ -1,38 +1,8 @@
 add_lldb_unittest(LLDBMinidumpTests
-  MinidumpParserTest.cpp
   RegisterContextMinidumpTest.cpp
 
   LINK_LIBS
-lldbCore
-lldbHost
-lldbTarget
-lldbPluginProcessUtility
 lldbPluginProcessMinidump
-lldbUtilityHelpers
-LLVMTestingSupport
   LIN

[Lldb-commits] [PATCH] D58970: Move RangeMap.h into Utility

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere accepted this revision.
JDevlieghere added a comment.
This revision is now accepted and ready to land.

This looks like a no-brainer. LGTM.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58970/new/

https://reviews.llvm.org/D58970



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

Re: [Lldb-commits] [lldb] r355406 - Revert "Fix embedded Python initialization according to changes in version 3.7"

[Davide Italiano via lldb-commits]

After the revert the testsuite doesn't hang anymore, so, it looks like
this was responsible. Stella, is the bot actually running python 3.6 ?
Can you make sure there's no python 3.7 installed somewhere in the
system that gets picked by accident?

On Tue, Mar 5, 2019 at 7:59 AM Davide Italiano  wrote:
>
> I'm also at a loss trying to understand how this particular change
> could've caused the tests to hang.
>
>   __VSCMD_PREINIT_PATH=C:\Program Files (x86)\Microsoft Visual
> Studio\Shared\Python36_64\Scripts\;C:\Program Files (x86)\Microsoft
> Visual 
> Studio\Shared\Python36_64\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program
> Files\dotnet\;C:\Program Files (x86)\GtkSharp\2.12\bin;C:\Program
> Files\CMake\bin;C:\Program Files (x86)\swigwin-3.0.12;C:\Program Files
> (x86)\GetGnuWin32\gnuwin32\bin;c:\Python27\Scripts\;C:\Program Files
> (x86)\Ninja;C:\Program Files\Git\cmd;C:\Program
> Files\TortoiseSVN\bin;C:\Users\buildslave\AppData\Local\Microsoft\WindowsApps;C:\Python27\lib\site-packages\pywin32_system32;C:\Python27\lib\site-packages\pywin32_system32
>  using PTY: False
>
>
> This is what I see on the Windows bot, so, I expect that it runs
> Python 3.6, but the whole fix is conditional to PY_MAJOR_VERSION == 3
> && PY_MINOR_VERSION >= 7.
>
> On Tue, Mar 5, 2019 at 7:53 AM Davide Italiano  wrote:
> >
> > This is unfortunate, because I think it's the correct path forward.
> > Stella, do you know why this is failing on Windows?
> >
> > Thanks,
> >
> > --
> > Davide
> >
> >
> > On Tue, Mar 5, 2019 at 7:26 AM Tatyana Krasnukha via lldb-commits
> >  wrote:
> > >
> > > Author: tkrasnukha
> > > Date: Tue Mar  5 07:27:33 2019
> > > New Revision: 355406
> > >
> > > URL: http://llvm.org/viewvc/llvm-project?rev=355406&view=rev
> > > Log:
> > > Revert "Fix embedded Python initialization according to changes in 
> > > version 3.7"
> > >
> > > Testsuite hangs on Windows likely due to these changes.
> > >
> > > Modified:
> > > 
> > > lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
> > >
> > > 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=355406&r1=355405&r2=355406&view=diff
> > > ==
> > > --- 
> > > lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
> > >  (original)
> > > +++ 
> > > lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
> > >  Tue Mar  5 07:27:33 2019
> > > @@ -156,7 +156,7 @@ public:
> > >  if (m_was_already_initialized) {
> > >Log 
> > > *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_SCRIPT));
> > >LLDB_LOGV(log, "Releasing PyGILState. Returning to state = 
> > > {0}locked",
> > > -m_gil_state == PyGILState_UNLOCKED ? "un" : "");
> > > +m_was_already_initialized == PyGILState_UNLOCKED ? "un" 
> > > : "");
> > >PyGILState_Release(m_gil_state);
> > >  } else {
> > >// We initialized the threads in this function, just unlock the 
> > > GIL.
> > > @@ -180,18 +180,6 @@ private:
> > >}
> > >
> > >void InitializeThreadsPrivate() {
> > > -// Since Python 3.7 `Py_Initialize` calls `PyEval_InitThreads` inside 
> > > itself,
> > > -// so there is no way to determine whether the embedded interpreter
> > > -// was already initialized by some external code. 
> > > `PyEval_ThreadsInitialized`
> > > -// would always return `true` and `PyGILState_Ensure/Release` flow would 
> > > be
> > > -// executed instead of unlocking GIL with `PyEval_SaveThread`. When
> > > -// an another thread calls `PyGILState_Ensure` it would get stuck in 
> > > deadlock.
> > > -#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 7) || 
> > > (PY_MAJOR_VERSION > 3)
> > > -// The only case we should go further and acquire the GIL: it is 
> > > unlocked.
> > > -if (PyGILState_Check())
> > > -  return;
> > > -#endif
> > > -
> > >  if (PyEval_ThreadsInitialized()) {
> > >Log 
> > > *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_SCRIPT));
> > >
> > >
> > >
> > > ___
> > > lldb-commits mailing list
> > > lldb-commits@lists.llvm.org
> > > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D58975: Introduce MinidumpEnums.def textual header

[Pavel Labath via Phabricator via lldb-commits]

labath created this revision.
labath added reviewers: zturner, lemo, clayborg, JDevlieghere, teemperor.
Herald added subscribers: fedor.sergeev, dschuff, srhines.
labath added a parent revision: D58973: Move the minidump parser into the 
Formats module.

The goal of this header is to reduce code duplication in code dealing
with various minidump constants (and having that code break when new
constants are added). It operates the same way as other llvm .def files:

- a user defines an appropriate macro which specifies the set of constants he 
wants to work with, and what he wants to do with it
- the user includes the .def file, which will invoke the user-defined macro for 
all known constants in the given set.

Right now, this defines only three constant sets, which correspond to
the ones I needed in followup patches, but others can (and probably
will) be easily added.


https://reviews.llvm.org/D58975

Files:
  include/lldb/Formats/MinidumpEnums.def
  include/lldb/Formats/MinidumpTypes.h
  include/lldb/module.modulemap
  source/Formats/MinidumpParser.cpp

Index: source/Formats/MinidumpParser.cpp
===
--- source/Formats/MinidumpParser.cpp
+++ source/Formats/MinidumpParser.cpp
@@ -649,58 +649,14 @@
   return m_regions;
 }
 
-#define ENUM_TO_CSTR(ST) case (uint32_t)MinidumpStreamType::ST: return #ST
-
 llvm::StringRef
 MinidumpParser::GetStreamTypeAsString(uint32_t stream_type) {
-  switch (stream_type) {
-ENUM_TO_CSTR(Unused);
-ENUM_TO_CSTR(Reserved0);
-ENUM_TO_CSTR(Reserved1);
-ENUM_TO_CSTR(ThreadList);
-ENUM_TO_CSTR(ModuleList);
-ENUM_TO_CSTR(MemoryList);
-ENUM_TO_CSTR(Exception);
-ENUM_TO_CSTR(SystemInfo);
-ENUM_TO_CSTR(ThreadExList);
-ENUM_TO_CSTR(Memory64List);
-ENUM_TO_CSTR(CommentA);
-ENUM_TO_CSTR(CommentW);
-ENUM_TO_CSTR(HandleData);
-ENUM_TO_CSTR(FunctionTable);
-ENUM_TO_CSTR(UnloadedModuleList);
-ENUM_TO_CSTR(MiscInfo);
-ENUM_TO_CSTR(MemoryInfoList);
-ENUM_TO_CSTR(ThreadInfoList);
-ENUM_TO_CSTR(HandleOperationList);
-ENUM_TO_CSTR(Token);
-ENUM_TO_CSTR(JavascriptData);
-ENUM_TO_CSTR(SystemMemoryInfo);
-ENUM_TO_CSTR(ProcessVMCounters);
-ENUM_TO_CSTR(BreakpadInfo);
-ENUM_TO_CSTR(AssertionInfo);
-ENUM_TO_CSTR(LinuxCPUInfo);
-ENUM_TO_CSTR(LinuxProcStatus);
-ENUM_TO_CSTR(LinuxLSBRelease);
-ENUM_TO_CSTR(LinuxCMDLine);
-ENUM_TO_CSTR(LinuxEnviron);
-ENUM_TO_CSTR(LinuxAuxv);
-ENUM_TO_CSTR(LinuxMaps);
-ENUM_TO_CSTR(LinuxDSODebug);
-ENUM_TO_CSTR(LinuxProcStat);
-ENUM_TO_CSTR(LinuxProcUptime);
-ENUM_TO_CSTR(LinuxProcFD);
-ENUM_TO_CSTR(FacebookAppCustomData);
-ENUM_TO_CSTR(FacebookBuildID);
-ENUM_TO_CSTR(FacebookAppVersionName);
-ENUM_TO_CSTR(FacebookJavaStack);
-ENUM_TO_CSTR(FacebookDalvikInfo);
-ENUM_TO_CSTR(FacebookUnwindSymbols);
-ENUM_TO_CSTR(FacebookDumpErrorLog);
-ENUM_TO_CSTR(FacebookAppStateLog);
-ENUM_TO_CSTR(FacebookAbortReason);
-ENUM_TO_CSTR(FacebookThreadName);
-ENUM_TO_CSTR(FacebookLogcat);
+  switch (MinidumpStreamType(stream_type)) {
+#define LLDB_HANDLE_STREAM_TYPE(CODE, NAME)\
+  case MinidumpStreamType::NAME:   \
+return #NAME;
+#include "lldb/Formats/MinidumpEnums.def"
+  default:
+return "unknown stream type";
   }
-  return "unknown stream type";
 }
Index: include/lldb/module.modulemap
===
--- include/lldb/module.modulemap
+++ include/lldb/module.modulemap
@@ -11,6 +11,9 @@
 
   umbrella "Formats"
   module * { export * }
+
+  // This header is intended for (repeated) textual inclusion.
+  textual header "Formats/MinidumpEnums.def"
 }
 
 module lldb_Host {
Index: include/lldb/Formats/MinidumpTypes.h
===
--- include/lldb/Formats/MinidumpTypes.h
+++ include/lldb/Formats/MinidumpTypes.h
@@ -53,99 +53,22 @@
 // Reference:
 // https://msdn.microsoft.com/en-us/library/windows/desktop/ms680394.aspx
 enum class MinidumpStreamType : uint32_t {
-  Unused = 0,
-  Reserved0 = 1,
-  Reserved1 = 2,
-  ThreadList = 3,
-  ModuleList = 4,
-  MemoryList = 5,
-  Exception = 6,
-  SystemInfo = 7,
-  ThreadExList = 8,
-  Memory64List = 9,
-  CommentA = 10,
-  CommentW = 11,
-  HandleData = 12,
-  FunctionTable = 13,
-  UnloadedModuleList = 14,
-  MiscInfo = 15,
-  MemoryInfoList = 16,
-  ThreadInfoList = 17,
-  HandleOperationList = 18,
-  Token = 19,
-  JavascriptData = 20,
-  SystemMemoryInfo = 21,
-  ProcessVMCounters = 22,
+#define LLDB_HANDLE_STREAM_TYPE(CODE, NAME) NAME = CODE,
+#include "lldb/Formats/MinidumpEnums.def"
   LastReserved = 0x,
-
-  /* Breakpad extension types.  0x4767 = "Gg" */
-  BreakpadInfo = 0x47670001,
-  AssertionInfo = 0x47670002,
-  /* These are additional minidump stream values which are specific to
-   * the linux 

[Lldb-commits] [PATCH] D58976: Introduce core2yaml tool

[Pavel Labath via Phabricator via lldb-commits]

labath created this revision.
labath added reviewers: zturner, lemo, clayborg, JDevlieghere.
Herald added a subscriber: mgorny.

This patch introduces the core2yaml tool, whose purpose is to dump core
files in a human readable (and, ideally, editable) format. It's very
similar to llvm's obj2yaml, except that it works with core files.

Currently, I only add basic support for dumping minidump files, but in
the future, the goal is to be able to dump ELF core files as well (hence
the generic name). Most of the code is implemented as a library (to
enable it being used from unit tests), with the actual executable only
being a very thin wrapper around that.

This patch only sets up the basic plumbing, and implements enough
functionality to be able to dump one of the simple minidump files we
have lying around. More functionality (including the tool for doing the
opposite conversion) will come in subsequent patches.


https://reviews.llvm.org/D58976

Files:
  include/lldb/Formats/MinidumpParser.h
  include/lldb/Formats/MinidumpTypes.h
  include/lldb/Formats/MinidumpYAML.h
  lit/tools/core2yaml/Inputs/basic-minidump.dmp
  lit/tools/core2yaml/basic-minidump.test
  source/Formats/CMakeLists.txt
  source/Formats/MinidumpParser.cpp
  source/Formats/MinidumpYAML.cpp
  source/Plugins/Process/minidump/ProcessMinidump.cpp
  tools/CMakeLists.txt
  tools/core2yaml/CMakeLists.txt
  tools/core2yaml/core2yaml.cpp
  unittests/Formats/MinidumpParserTest.cpp

Index: unittests/Formats/MinidumpParserTest.cpp
===
--- unittests/Formats/MinidumpParserTest.cpp
+++ unittests/Formats/MinidumpParserTest.cpp
@@ -38,10 +38,10 @@
 
   void SetUpData(const char *minidump_filename) {
 std::string filename = GetInputFilePath(minidump_filename);
-auto BufferPtr = FileSystem::Instance().CreateDataBuffer(filename, -1, 0);
-ASSERT_NE(BufferPtr, nullptr);
+data_sp = FileSystem::Instance().CreateDataBuffer(filename, -1, 0);
+ASSERT_NE(data_sp, nullptr);
 llvm::Expected expected_parser =
-MinidumpParser::Create(BufferPtr);
+MinidumpParser::Create(data_sp->GetData());
 ASSERT_THAT_EXPECTED(expected_parser, llvm::Succeeded());
 parser = std::move(*expected_parser);
 ASSERT_GT(parser->GetData().size(), 0UL);
@@ -53,9 +53,11 @@
 FileSystem::Instance().CreateDataBuffer(filename, load_size, 0);
 ASSERT_NE(BufferPtr, nullptr);
 
-EXPECT_THAT_EXPECTED(MinidumpParser::Create(BufferPtr), llvm::Failed());
+EXPECT_THAT_EXPECTED(MinidumpParser::Create(BufferPtr->GetData()),
+ llvm::Failed());
   }
 
+  lldb::DataBufferSP data_sp;
   llvm::Optional parser;
 };
 
Index: tools/core2yaml/core2yaml.cpp
===
--- /dev/null
+++ tools/core2yaml/core2yaml.cpp
@@ -0,0 +1,59 @@
+//===-- core2yaml.cpp *- C++-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/Formats/MinidumpParser.h"
+#include "lldb/Formats/MinidumpTypes.h"
+#include "lldb/Formats/MinidumpYAML.h"
+#include "lldb/Utility/DataBufferHeap.h"
+#include "llvm/Support/CommandLine.h"
+#include "llvm/Support/Error.h"
+
+using namespace lldb_private;
+using namespace lldb_private::minidump;
+namespace yaml = llvm::yaml;
+namespace cl = llvm::cl;
+
+
+static llvm::Error dumpInput(llvm::StringRef File) {
+  auto BufferOrErr = llvm::MemoryBuffer::getFileOrSTDIN(
+  File, /*FileSize*/ -1, /*RequiresNullTerminator*/ false);
+  if (!BufferOrErr)
+return llvm::errorCodeToError(BufferOrErr.getError());
+  llvm::Expected Parser = MinidumpParser::Create(
+  arrayRefFromStringRef(BufferOrErr->get()->getBuffer()));
+  if (!Parser)
+return Parser.takeError();
+
+  yaml::Output yout(llvm::outs());
+  auto ExpectedModel = Object::create(*Parser);
+  if (!ExpectedModel)
+return ExpectedModel.takeError();
+  yout << *ExpectedModel;
+  return llvm::Error::success();
+}
+
+static void reportError(llvm::StringRef Input, llvm::Error Err) {
+  if (Input == "-")
+Input = "";
+  llvm::errs() << "Error reading file: " << Input << ": ";
+  logAllUnhandledErrors(std::move(Err), llvm::errs());
+}
+
+static cl::opt
+InputFilename(cl::Positional, cl::desc(""), cl::init("-"));
+
+int main(int argc, char *argv[]) {
+  cl::ParseCommandLineOptions(argc, argv);
+
+  if (llvm::Error Err = dumpInput(InputFilename)) {
+reportError(InputFilename, std::move(Err));
+return 1;
+  }
+
+  return 0;
+}
Index: tools/core2yaml/CMakeLists.txt
===
--- /dev/null
+++ tools/core2yaml/CMakeLists.txt
@@ -0,0 +1,10 @@
+add_lldb_tool(core2yaml
+  core2y

[Lldb-commits] [PATCH] D58962: Sanity check --max-gdbserver-port

[Jan Kratochvil via Phabricator via lldb-commits]

jankratochvil updated this revision to Diff 189333.
jankratochvil added a comment.
Herald added a reviewer: serge-sans-paille.

There is no `not` as `lldb-server` still had+has exit code 0 during this error.
I have no idea what to put to the `FIXME` string there. Failure (with old 
`lldb-server`) looks as:

  FAIL: LLDB :: Driver/TestGdbserverPort.test (8 of 1551)
   TEST 'LLDB :: Driver/TestGdbserverPort.test' FAILED 

  Script:
  --
  : 'RUN: at line 1';   
/home/jkratoch/redhat/llvm-monorepo-clangassert/bin/lldb-server platform p 
--server --listen :1234 --min-gdbserver-port 1234 --max-gdbserver-port 1234 
2>&1 | /home/jkratoch/redhat/llvm-monorepo-clangassert/bin/FileCheck 
/home/jkratoch/redhat/llvm-monorepo/lldb/lit/Driver/TestGdbserverPort.test
  --
  Exit Code: 1
  
  Command Output (stderr):
  --
  
/home/jkratoch/redhat/llvm-monorepo/lldb/lit/Driver/TestGdbserverPort.test:2:10:
 error: CHECK: expected string not found in input
  # CHECK: error: --min-gdbserver-port (1234) is not lower than 
--max-gdbserver-port (1234)
   ^
  :1:1: note: scanning from here
  failed to listen: Address already in use
  ^


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58962/new/

https://reviews.llvm.org/D58962

Files:
  lldb/lit/Driver/TestGdbserverPort.test
  lldb/lit/helper/toolchain.py
  lldb/tools/lldb-server/lldb-platform.cpp


Index: lldb/tools/lldb-server/lldb-platform.cpp
===
--- lldb/tools/lldb-server/lldb-platform.cpp
+++ lldb/tools/lldb-server/lldb-platform.cpp
@@ -241,11 +241,11 @@
 return -1;
 
   // Make a port map for a port range that was specified.
-  if (min_gdbserver_port < max_gdbserver_port) {
+  if (min_gdbserver_port && min_gdbserver_port < max_gdbserver_port) {
 for (uint16_t port = min_gdbserver_port; port < max_gdbserver_port; ++port)
   gdbserver_portmap[port] = LLDB_INVALID_PROCESS_ID;
-  } else if (min_gdbserver_port != max_gdbserver_port) {
-fprintf(stderr, "error: --min-gdbserver-port (%u) is greater than "
+  } else if (min_gdbserver_port || max_gdbserver_port) {
+fprintf(stderr, "error: --min-gdbserver-port (%u) is not lower than "
 "--max-gdbserver-port (%u)\n",
 min_gdbserver_port, max_gdbserver_port);
 option_error = 3;
Index: lldb/lit/helper/toolchain.py
===
--- lldb/lit/helper/toolchain.py
+++ lldb/lit/helper/toolchain.py
@@ -16,6 +16,7 @@
 
 dsname = 'debugserver' if platform.system() in ['Darwin'] else 
'lldb-server'
 dsargs = [] if platform.system() in ['Darwin'] else ['gdbserver']
+psargs = ['FIXME'] if platform.system() in ['Darwin'] else ['platform']
 lldbmi = ToolSubst('%lldbmi',
command=FindTool('lldb-mi'),
extra_args=['--synchronous'],
@@ -43,6 +44,10 @@
   command=FindTool(dsname),
   extra_args=dsargs,
   unresolved='ignore'),
+ToolSubst('%platformserver',
+  command=FindTool(dsname),
+  extra_args=psargs,
+  unresolved='ignore'),
 'lldb-test',
 'lldb-instr',
 ToolSubst('%build',
Index: lldb/lit/Driver/TestGdbserverPort.test
===
--- /dev/null
+++ lldb/lit/Driver/TestGdbserverPort.test
@@ -0,0 +1,2 @@
+# RUN: %platformserver p --server --listen :1234 --min-gdbserver-port 1234 
--max-gdbserver-port 1234 2>&1 | FileCheck %s
+# CHECK: error: --min-gdbserver-port (1234) is not lower than 
--max-gdbserver-port (1234)


Index: lldb/tools/lldb-server/lldb-platform.cpp
===
--- lldb/tools/lldb-server/lldb-platform.cpp
+++ lldb/tools/lldb-server/lldb-platform.cpp
@@ -241,11 +241,11 @@
 return -1;
 
   // Make a port map for a port range that was specified.
-  if (min_gdbserver_port < max_gdbserver_port) {
+  if (min_gdbserver_port && min_gdbserver_port < max_gdbserver_port) {
 for (uint16_t port = min_gdbserver_port; port < max_gdbserver_port; ++port)
   gdbserver_portmap[port] = LLDB_INVALID_PROCESS_ID;
-  } else if (min_gdbserver_port != max_gdbserver_port) {
-fprintf(stderr, "error: --min-gdbserver-port (%u) is greater than "
+  } else if (min_gdbserver_port || max_gdbserver_port) {
+fprintf(stderr, "error: --min-gdbserver-port (%u) is not lower than "
 "--max-gdbserver-port (%u)\n",
 min_gdbserver_port, max_gdbserver_port);
 option_error = 3;
Index: lldb/lit/helper/toolchain.py
===
--- lldb/lit/helper/toolchain.py
+++ lldb/lit/helper/toolchain.py
@@ -16,6 +16,7 @@
 
 dsname = 'debugserver' if platform.system() in ['Darwin'] else 'lldb-server'
 dsargs = [] if platform.system

[Lldb-commits] [PATCH] D58971: Move MemoryRegionInfo into the Utility module

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere added a comment.

I like the idea of having a separate module for this.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58971/new/

https://reviews.llvm.org/D58971



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

Re: [Lldb-commits] [lldb] r355406 - Revert "Fix embedded Python initialization according to changes in version 3.7"

[Stella Stamenova via lldb-commits]

The bot is running 3.6.6 and it does not have python 3.7 installed (it does 
have python 2.7 which is needed to run Buildbot).

The change that was pushed, though, did not only impact python 3.7:

m_was_already_initialized == PyGILState_UNLOCKED ? "un" : "");
m_gil_state == PyGILState_UNLOCKED ? "un" : "");

It replaced m_was_already_initialized above with m_gil_state - for *any* 
version of python. Yes, this is just in a log, but my guess is that that's the 
source of the hang on Windows not the 3.7 specific code. 

If you end up with a  prototype change that you want to commit, I can run a 
local test to see whether the tests pass with it.

Thanks,
-Stella

-Original Message-
From: Davide Italiano  
Sent: Tuesday, March 5, 2019 8:26 AM
To: Tatyana Krasnukha ; Stella Stamenova 

Cc: lldb-commits 
Subject: Re: [Lldb-commits] [lldb] r355406 - Revert "Fix embedded Python 
initialization according to changes in version 3.7"

After the revert the testsuite doesn't hang anymore, so, it looks like this was 
responsible. Stella, is the bot actually running python 3.6 ?
Can you make sure there's no python 3.7 installed somewhere in the system that 
gets picked by accident?

On Tue, Mar 5, 2019 at 7:59 AM Davide Italiano  wrote:
>
> I'm also at a loss trying to understand how this particular change 
> could've caused the tests to hang.
>
>   __VSCMD_PREINIT_PATH=C:\Program Files (x86)\Microsoft Visual 
> Studio\Shared\Python36_64\Scripts\;C:\Program Files (x86)\Microsoft 
> Visual 
> Studio\Shared\Python36_64\;C:\Windows\system32;C:\Windows;C:\Windows\S
> ystem32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program
> Files\dotnet\;C:\Program Files (x86)\GtkSharp\2.12\bin;C:\Program
> Files\CMake\bin;C:\Program Files (x86)\swigwin-3.0.12;C:\Program Files 
> (x86)\GetGnuWin32\gnuwin32\bin;c:\Python27\Scripts\;C:\Program Files 
> (x86)\Ninja;C:\Program Files\Git\cmd;C:\Program
> Files\TortoiseSVN\bin;C:\Users\buildslave\AppData\Local\Microsoft\Wind
> owsApps;C:\Python27\lib\site-packages\pywin32_system32;C:\Python27\lib
> \site-packages\pywin32_system32
>  using PTY: False
>
>
> This is what I see on the Windows bot, so, I expect that it runs 
> Python 3.6, but the whole fix is conditional to PY_MAJOR_VERSION == 3 
> && PY_MINOR_VERSION >= 7.
>
> On Tue, Mar 5, 2019 at 7:53 AM Davide Italiano  wrote:
> >
> > This is unfortunate, because I think it's the correct path forward.
> > Stella, do you know why this is failing on Windows?
> >
> > Thanks,
> >
> > --
> > Davide
> >
> >
> > On Tue, Mar 5, 2019 at 7:26 AM Tatyana Krasnukha via lldb-commits 
> >  wrote:
> > >
> > > Author: tkrasnukha
> > > Date: Tue Mar  5 07:27:33 2019
> > > New Revision: 355406
> > >
> > > URL: 
> > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fl
> > > lvm.org%2Fviewvc%2Fllvm-project%3Frev%3D355406%26view%3Drev&da
> > > ta=02%7C01%7CSTILIS%40microsoft.com%7Cc10a6a537cd64f69e2cb08d6a187
> > > 4c51%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6368739998069545
> > > 86&sdata=lVokkbUu5XHoInVa4sYLT90X%2Fqj%2BJOcWcUkSD%2BdCyDQ%3D&
> > > amp;reserved=0
> > > Log:
> > > Revert "Fix embedded Python initialization according to changes in 
> > > version 3.7"
> > >
> > > Testsuite hangs on Windows likely due to these changes.
> > >
> > > Modified:
> > > 
> > > lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpret
> > > erPython.cpp
> > >
> > > Modified: 
> > > lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpret
> > > erPython.cpp
> > > URL: 
> > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fl
> > > lvm.org%2Fviewvc%2Fllvm-project%2Flldb%2Ftrunk%2Fsource%2FPlugins%
> > > 2FScriptInterpreter%2FPython%2FScriptInterpreterPython.cpp%3Frev%3
> > > D355406%26r1%3D355405%26r2%3D355406%26view%3Ddiff&data=02%7C01
> > > %7CSTILIS%40microsoft.com%7Cc10a6a537cd64f69e2cb08d6a1874c51%7C72f
> > > 988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636873999806954586&sda
> > > ta=WOgZzE1py846x%2FJjvG%2F3SqCwXWOfMMqBtzS22GUITCw%3D&reserved
> > > =0 
> > > ==
> > > 
> > > --- 
> > > lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpret
> > > erPython.cpp (original)
> > > +++ lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInter
> > > +++ preterPython.cpp Tue Mar  5 07:27:33 2019
> > > @@ -156,7 +156,7 @@ public:
> > >  if (m_was_already_initialized) {
> > >Log 
> > > *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_SCRIPT));
> > >LLDB_LOGV(log, "Releasing PyGILState. Returning to state = 
> > > {0}locked",
> > > -m_gil_state == PyGILState_UNLOCKED ? "un" : "");
> > > +m_was_already_initialized == PyGILState_UNLOCKED 
> > > + ? "un" : "");
> > >PyGILState_Release(m_gil_state);
> > >  } else {
> > >// We initialized the threads in this function, just unlock the 
> > > GIL.
> > > @@ -180,18 +180,6 @

Re: [Lldb-commits] [PATCH] D58946: [SBAPI] Don't check IsValid in constructor

[Pavel Labath via lldb-commits]

On 05/03/2019 17:19, Jonas Devlieghere wrote:
Sounds good, I’ll make this change before landing, unless you have 
further comments?


On Tue, Mar 5, 2019 at 4:29 AM Pavel Labath via Phabricator 
mailto:revi...@reviews.llvm.org>> wrote:


labath added a comment.

The copy constructors and assignment operators are very repetitive.
What would you say to a function like

   template
   void clone(std::unique_ptr &dest, const std::unique_ptr &src) {
   if (&dest == &src)
     return;
   if (src)
     dest = llvm::make_unique(*src);
   else
     dest.reset();
   }

(and a similar one for shared_ptrs)? Then both copy constructors and
assignment operators could be just implemented as `clone(m_whatever,
rhs.m_whatever);`. (Assuming we don't care about pessimizing the
self-assignment case this could even be `m_whatever =
clone(rhs.m_whatever);`)


Repository:
   rLLDB LLDB

CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D58946/new/

https://reviews.llvm.org/D58946




Yeah, that's fine. The only thing I could possibly add is that this 
approach depends on not "mirroring" the default constructor, which is 
the thing you were trying to the in the original patch, and I don't 
think it's right or necessary.
It's not right because I think a copy constructor should make a exact 
copy, regardless of what the default constructor of the same object 
would create.
And it's not necessary because if the default constructor already 
initializes the unique_ptr member (which is the thing you are trying to 
mirror), then you should not ever encounter a object with an empty 
unique_ptr to copy from.


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

[Lldb-commits] [PATCH] D58976: Introduce core2yaml tool

[Greg Clayton via Phabricator via lldb-commits]

clayborg added a comment.

Do we want this in LLVM instead of lldb?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58976/new/

https://reviews.llvm.org/D58976



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

Re: [Lldb-commits] [lldb] r355406 - Revert "Fix embedded Python initialization according to changes in version 3.7"

[Davide Italiano via lldb-commits]

On Tue, Mar 5, 2019 at 8:39 AM Stella Stamenova  wrote:
>
> The bot is running 3.6.6 and it does not have python 3.7 installed (it does 
> have python 2.7 which is needed to run Buildbot).
>
> The change that was pushed, though, did not only impact python 3.7:
>
> m_was_already_initialized == PyGILState_UNLOCKED ? "un" : "");
> m_gil_state == PyGILState_UNLOCKED ? "un" : "");
>
> It replaced m_was_already_initialized above with m_gil_state - for *any* 
> version of python. Yes, this is just in a log, but my guess is that that's 
> the source of the hang on Windows not the 3.7 specific code.
>
> If you end up with a  prototype change that you want to commit, I can run a 
> local test to see whether the tests pass with it.
>

Can you just revert that chunk of unconditional python code and try?
(it's extremely surprising to me that the change caused the bots to
hang, even if it's unconditional, anyway).

i.e.

+// Since Python 3.7 `Py_Initialize` calls `PyEval_InitThreads` inside itself,
+// so there is no way to determine whether the embedded interpreter
+// was already initialized by some external code. `PyEval_ThreadsInitialized`
+// would always return `true` and `PyGILState_Ensure/Release` flow would be
+// executed instead of unlocking GIL with `PyEval_SaveThread`. When
+// an another thread calls `PyGILState_Ensure` it would get stuck in deadlock.
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 7) || (PY_MAJOR_VERSION > 3)
+// The only case we should go further and acquire the GIL: it is unlocked.
+if (PyGILState_Check())
+  return;
+#endif
+

and let us know if the bot still hangs?

Thanks,

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

[Lldb-commits] [PATCH] D57689: Adds property to force enabling of GDB JIT loader for MacOS

[Stella Stamenova via Phabricator via lldb-commits]

stella.stamenova added a comment.

This is causing a failure on the Windows Bot:

http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/2299/steps/test/logs/stdio

It was broken because of another change which is why you probably didn't get a 
notification. Please, fix this quickly or revert the change, so that we don't 
end up with more failures that are not sending notifications because the bot's 
been broken all morning.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57689/new/

https://reviews.llvm.org/D57689



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

[Lldb-commits] [PATCH] D58962: Sanity check --max-gdbserver-port

[Pavel Labath via Phabricator via lldb-commits]

labath added inline comments.



Comment at: lldb/lit/helper/toolchain.py:19
 dsargs = [] if platform.system() in ['Darwin'] else ['gdbserver']
+psargs = ['FIXME'] if platform.system() in ['Darwin'] else ['platform']
 lldbmi = ToolSubst('%lldbmi',

For the "platform" mode, Darwin uses lldb-server like other platforms. So this 
should just be "lldb-server platform" unconditionally.


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58962/new/

https://reviews.llvm.org/D58962



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

[Lldb-commits] [PATCH] D58976: Introduce core2yaml tool

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In D58976#1418596 , @clayborg wrote:

> Do we want this in LLVM instead of lldb?


The thought has crossed my mind, but for that I would have to also move the 
minidump parser into llvm. It's already pretty standalone, so it shouldn't be a 
problem technically, but it's not clear to me whether there is any use case for 
it in llvm. This is a core file format, and I don't know of any other llvm 
tool/project working with core files.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58976/new/

https://reviews.llvm.org/D58976



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

Re: [Lldb-commits] [PATCH] D58946: [SBAPI] Don't check IsValid in constructor

[Jonas Devlieghere via lldb-commits]

On Tue, Mar 5, 2019 at 8:41 AM Pavel Labath  wrote:

> On 05/03/2019 17:19, Jonas Devlieghere wrote:
> > Sounds good, I’ll make this change before landing, unless you have
> > further comments?
> >
> > On Tue, Mar 5, 2019 at 4:29 AM Pavel Labath via Phabricator
> > mailto:revi...@reviews.llvm.org>> wrote:
> >
> > labath added a comment.
> >
> > The copy constructors and assignment operators are very repetitive.
> > What would you say to a function like
> >
> >template
> >void clone(std::unique_ptr &dest, const std::unique_ptr
> &src) {
> >if (&dest == &src)
> >  return;
> >if (src)
> >  dest = llvm::make_unique(*src);
> >else
> >  dest.reset();
> >}
> >
> > (and a similar one for shared_ptrs)? Then both copy constructors and
> > assignment operators could be just implemented as `clone(m_whatever,
> > rhs.m_whatever);`. (Assuming we don't care about pessimizing the
> > self-assignment case this could even be `m_whatever =
> > clone(rhs.m_whatever);`)
> >
> >
> > Repository:
> >rLLDB LLDB
> >
> > CHANGES SINCE LAST ACTION
> > https://reviews.llvm.org/D58946/new/
> >
> > https://reviews.llvm.org/D58946
> >
> >
>
> Yeah, that's fine. The only thing I could possibly add is that this
> approach depends on not "mirroring" the default constructor, which is
> the thing you were trying to the in the original patch, and I don't
> think it's right or necessary.
>

I thought the same yesterday. The difference is the result of always being
able to create a default object form Python. However, not all SB objects
have a default construct. Some things are not valid unless they are
returned by a factory. That's the reason that some objects always
initialize their opaque pointer, and some don't. The mirroring of the
default constructor is to retrain this semantic in the copy constructor.


> It's not right because I think a copy constructor should make a exact
> copy, regardless of what the default constructor of the same object
> would create.
>

I think we agree, but just to be sure: an exact copy of what? The lldb
object or the lldb_private object?


> And it's not necessary because if the default constructor already
> initializes the unique_ptr member (which is the thing you are trying to
> mirror), then you should not ever encounter a object with an empty
> unique_ptr to copy from.
>

Yes, if all code paths initialize the opaque pointer and nothing every
unsets it, then this is true. Then we can also remove all the spurious
if(opaque_ptr) checks. But what about classes that don't initialize their
unique pointer, they still need to be copyable.


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

[Lldb-commits] [PATCH] D58962: Sanity check --max-gdbserver-port

[Jan Kratochvil via Phabricator via lldb-commits]

jankratochvil updated this revision to Diff 189338.
jankratochvil marked an inline comment as done.

Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58962/new/

https://reviews.llvm.org/D58962

Files:
  lldb/lit/Driver/TestGdbserverPort.test
  lldb/lit/helper/toolchain.py
  lldb/tools/lldb-server/lldb-platform.cpp


Index: lldb/tools/lldb-server/lldb-platform.cpp
===
--- lldb/tools/lldb-server/lldb-platform.cpp
+++ lldb/tools/lldb-server/lldb-platform.cpp
@@ -241,11 +241,11 @@
 return -1;
 
   // Make a port map for a port range that was specified.
-  if (min_gdbserver_port < max_gdbserver_port) {
+  if (min_gdbserver_port && min_gdbserver_port < max_gdbserver_port) {
 for (uint16_t port = min_gdbserver_port; port < max_gdbserver_port; ++port)
   gdbserver_portmap[port] = LLDB_INVALID_PROCESS_ID;
-  } else if (min_gdbserver_port != max_gdbserver_port) {
-fprintf(stderr, "error: --min-gdbserver-port (%u) is greater than "
+  } else if (min_gdbserver_port || max_gdbserver_port) {
+fprintf(stderr, "error: --min-gdbserver-port (%u) is not lower than "
 "--max-gdbserver-port (%u)\n",
 min_gdbserver_port, max_gdbserver_port);
 option_error = 3;
Index: lldb/lit/helper/toolchain.py
===
--- lldb/lit/helper/toolchain.py
+++ lldb/lit/helper/toolchain.py
@@ -43,6 +43,10 @@
   command=FindTool(dsname),
   extra_args=dsargs,
   unresolved='ignore'),
+ToolSubst('%platformserver',
+  command=FindTool('lldb-server'),
+  extra_args=['platform'],
+  unresolved='ignore'),
 'lldb-test',
 'lldb-instr',
 ToolSubst('%build',
Index: lldb/lit/Driver/TestGdbserverPort.test
===
--- /dev/null
+++ lldb/lit/Driver/TestGdbserverPort.test
@@ -0,0 +1,2 @@
+# RUN: %platformserver p --server --listen :1234 --min-gdbserver-port 1234 
--max-gdbserver-port 1234 2>&1 | FileCheck %s
+# CHECK: error: --min-gdbserver-port (1234) is not lower than 
--max-gdbserver-port (1234)


Index: lldb/tools/lldb-server/lldb-platform.cpp
===
--- lldb/tools/lldb-server/lldb-platform.cpp
+++ lldb/tools/lldb-server/lldb-platform.cpp
@@ -241,11 +241,11 @@
 return -1;
 
   // Make a port map for a port range that was specified.
-  if (min_gdbserver_port < max_gdbserver_port) {
+  if (min_gdbserver_port && min_gdbserver_port < max_gdbserver_port) {
 for (uint16_t port = min_gdbserver_port; port < max_gdbserver_port; ++port)
   gdbserver_portmap[port] = LLDB_INVALID_PROCESS_ID;
-  } else if (min_gdbserver_port != max_gdbserver_port) {
-fprintf(stderr, "error: --min-gdbserver-port (%u) is greater than "
+  } else if (min_gdbserver_port || max_gdbserver_port) {
+fprintf(stderr, "error: --min-gdbserver-port (%u) is not lower than "
 "--max-gdbserver-port (%u)\n",
 min_gdbserver_port, max_gdbserver_port);
 option_error = 3;
Index: lldb/lit/helper/toolchain.py
===
--- lldb/lit/helper/toolchain.py
+++ lldb/lit/helper/toolchain.py
@@ -43,6 +43,10 @@
   command=FindTool(dsname),
   extra_args=dsargs,
   unresolved='ignore'),
+ToolSubst('%platformserver',
+  command=FindTool('lldb-server'),
+  extra_args=['platform'],
+  unresolved='ignore'),
 'lldb-test',
 'lldb-instr',
 ToolSubst('%build',
Index: lldb/lit/Driver/TestGdbserverPort.test
===
--- /dev/null
+++ lldb/lit/Driver/TestGdbserverPort.test
@@ -0,0 +1,2 @@
+# RUN: %platformserver p --server --listen :1234 --min-gdbserver-port 1234 --max-gdbserver-port 1234 2>&1 | FileCheck %s
+# CHECK: error: --min-gdbserver-port (1234) is not lower than --max-gdbserver-port (1234)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D58976: Introduce core2yaml tool

[Greg Clayton via Phabricator via lldb-commits]

clayborg added inline comments.



Comment at: include/lldb/Formats/MinidumpParser.h:105
 private:
-  lldb::DataBufferSP m_data_sp;
+  llvm::ArrayRef m_data;
+  const MinidumpHeader *m_header;

I worry about this going stale when the owner of the data lets it go and we 
crash now that we don't have strong ownership. If this is common in LLVM, then 
we need to document this in the header file.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58976/new/

https://reviews.llvm.org/D58976



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

[Lldb-commits] [PATCH] D58976: Introduce core2yaml tool

[Greg Clayton via Phabricator via lldb-commits]

clayborg added a comment.

Strong ownership is needed for this class IMHO because it hands out pointers to 
native data


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58976/new/

https://reviews.llvm.org/D58976



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

[Lldb-commits] [lldb] r355415 - Revert "[lldbtest] Check against the correct name for libcxxabi (macOS)."

[Davide Italiano via lldb-commits]

Author: davide
Date: Tue Mar  5 09:21:55 2019
New Revision: 355415

URL: http://llvm.org/viewvc/llvm-project?rev=355415&view=rev
Log:
Revert "[lldbtest] Check against the correct name for libcxxabi (macOS)."

This passes locally but breaks on the bots. Maybe an SDK difference.
Reverting while I investigate.

Modified:
lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py

Modified: lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py?rev=355415&r1=355414&r2=355415&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py Tue Mar  5 09:21:55 
2019
@@ -1703,7 +1703,7 @@ class Base(unittest2.TestCase):
 if self.getPlatform() in ('freebsd', 'linux', 'netbsd', 'openbsd'):
 return ['libc++.so.1']
 else:
-return ['libc++.1.dylib', 'libc++abi.1.dylib']
+return ['libc++.1.dylib', 'libc++abi.dylib']
 
 # Metaclass for TestBase to change the list of test metods when a new TestCase 
is loaded.
 # We change the test methods to create a new test method for each test for 
each debug info we are


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

[Lldb-commits] [PATCH] D58962: Sanity check --max-gdbserver-port

[Jason Molenda via Phabricator via lldb-commits]

jasonmolenda added a comment.

LGTM fwiw I think the --min-gdbserver-port and --max-gdbserver-port options 
were primarily/only used for iOS etc testsuite runs, where a fixed set of ports 
is relayed between the devices.  I was having some problems with lldb-server in 
platform mode on these devices and thought it would be nice to have a 
standalone implementation of the platform protocol packets, so I wrote one a 
couple months ago and that's what we're using now for this environment.  I 
should probably upstream it, I think it would work on linux too, it doesn't use 
any of lldb/llvm so it has several areas that are primitive because I was going 
for "good enough" and moving on, e.g. it has a dumb logging class and the 
networking could use some work, etc.  I want to keep this completely free of 
lldb/llvm dependencies so it's a little bit of an oddball.


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58962/new/

https://reviews.llvm.org/D58962



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

[Lldb-commits] [PATCH] D58976: Introduce core2yaml tool

[Zachary Turner via Phabricator via lldb-commits]

zturner added a comment.

In D58976#1418621 , @clayborg wrote:

> Strong ownership is needed for this class IMHO because it hands out pointers 
> to native data


I disagree here, see my previous comment.  Binaries grow large very quickly, 
and if we always copy data around when we want to hand out some internal 
pointer, memory usage would explode.  Luckily, the scenario that attempts to 
prevent is very rare.  Specifically, it only addresses the scenario where you 
open a file, parse a bunch of data, close the file, then still expect to be 
able to do something with the file's internal data structures.  I haven't ever 
seen this be a problem in practice, as the "natural" order is to open a file, 
process it, then close the file.  And in that case this is fine.

I don't mind having it be documented in the class header, but given that the 
pattern is fairly pervasive in LLVM (e.g. all of lib/Object works this way, 
among other things), I'm also fine with just letting it be implicitly 
understood.




Comment at: include/lldb/Formats/MinidumpParser.h:105
 private:
-  lldb::DataBufferSP m_data_sp;
+  llvm::ArrayRef m_data;
+  const MinidumpHeader *m_header;

clayborg wrote:
> I worry about this going stale when the owner of the data lets it go and we 
> crash now that we don't have strong ownership. If this is common in LLVM, 
> then we need to document this in the header file.
This is a fairly pervasive, as well as being an important optimization.  We 
don't want to be copying data around from binary files because the amount of 
data that ends up being copied could quickly spiral out of control since 
binaries get quite large.  The semantics are that the data is valid as long as 
the backing file remains opened.  Anyone using the class needs to be aware of 
this, and if they want a lifetime that is not tied to the life of the backing 
file (which is a fairly uncommon scenario), they need to explicitly copy any 
data they need to outlive the file.



CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58976/new/

https://reviews.llvm.org/D58976



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

Re: [Lldb-commits] [lldb] r355375 - [Expression] Remove unused parameter from Evaluate

[Jim Ingham via lldb-commits]

If you don't mind, I would like to revert this patch.  Though the parameter is 
currently unused on the llvm.org side, it is used in the Swift REPL, so 
removing it causes unnecessary conflicts.  Also, it will be necessary to 
support any kind of REPL - Sean gave a talk a couple of years ago at the llvm 
conference about doing a C++ REPL in lldb so this is not entirely 
speculative... So I'd like to keep it plumbed through.  I can't see that it 
does any harm.

Jim

> On Mar 4, 2019, at 7:33 PM, Alex Langford via lldb-commits 
>  wrote:
> 
> Author: xiaobai
> Date: Mon Mar  4 19:33:34 2019
> New Revision: 355375
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=355375&view=rev
> Log:
> [Expression] Remove unused parameter from Evaluate
> 
> Modified:
>lldb/trunk/include/lldb/Expression/UserExpression.h
>lldb/trunk/source/Expression/REPL.cpp
>lldb/trunk/source/Expression/UserExpression.cpp
>lldb/trunk/source/Target/Target.cpp
> 
> Modified: lldb/trunk/include/lldb/Expression/UserExpression.h
> URL: 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Expression/UserExpression.h?rev=355375&r1=355374&r2=355375&view=diff
> ==
> --- lldb/trunk/include/lldb/Expression/UserExpression.h (original)
> +++ lldb/trunk/include/lldb/Expression/UserExpression.h Mon Mar  4 19:33:34 
> 2019
> @@ -261,10 +261,6 @@ public:
>   /// Filled in with an error in case the expression evaluation
>   /// fails to parse, run, or evaluated.
>   ///
> -  /// @param[in] line_offset
> -  /// The offset of the first line of the expression from the 
> "beginning" of
> -  /// a virtual source file used for error reporting and debug info.
> -  ///
>   /// @param[out] fixed_expression
>   /// If non-nullptr, the fixed expression is copied into the provided
>   /// string.
> @@ -290,7 +286,7 @@ public:
>   Evaluate(ExecutionContext &exe_ctx, const EvaluateExpressionOptions 
> &options,
>llvm::StringRef expr_cstr, llvm::StringRef expr_prefix,
>lldb::ValueObjectSP &result_valobj_sp, Status &error,
> -   uint32_t line_offset = 0, std::string *fixed_expression = nullptr,
> +   std::string *fixed_expression = nullptr,
>lldb::ModuleSP *jit_module_sp_ptr = nullptr,
>ValueObject *ctx_obj = nullptr);
> 
> 
> Modified: lldb/trunk/source/Expression/REPL.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Expression/REPL.cpp?rev=355375&r1=355374&r2=355375&view=diff
> ==
> --- lldb/trunk/source/Expression/REPL.cpp (original)
> +++ lldb/trunk/source/Expression/REPL.cpp Mon Mar  4 19:33:34 2019
> @@ -307,7 +307,6 @@ void REPL::IOHandlerInputComplete(IOHand
>   lldb::ExpressionResults execution_results =
>   UserExpression::Evaluate(exe_ctx, expr_options, code.c_str(),
>expr_prefix, result_valobj_sp, error,
> -   0,   // Line offset
>nullptr, // Fixed Expression
>&jit_module_sp);
> 
> 
> Modified: lldb/trunk/source/Expression/UserExpression.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Expression/UserExpression.cpp?rev=355375&r1=355374&r2=355375&view=diff
> ==
> --- lldb/trunk/source/Expression/UserExpression.cpp (original)
> +++ lldb/trunk/source/Expression/UserExpression.cpp Mon Mar  4 19:33:34 2019
> @@ -139,7 +139,7 @@ lldb::addr_t UserExpression::GetObjectPo
> lldb::ExpressionResults UserExpression::Evaluate(
> ExecutionContext &exe_ctx, const EvaluateExpressionOptions &options,
> llvm::StringRef expr, llvm::StringRef prefix,
> -lldb::ValueObjectSP &result_valobj_sp, Status &error, uint32_t 
> line_offset,
> +lldb::ValueObjectSP &result_valobj_sp, Status &error,
> std::string *fixed_expression, lldb::ModuleSP *jit_module_sp_ptr,
> ValueObject *ctx_obj) {
>   Log *log(lldb_private::GetLogIfAnyCategoriesSet(LIBLLDB_LOG_EXPRESSIONS |
> 
> Modified: lldb/trunk/source/Target/Target.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/Target.cpp?rev=355375&r1=355374&r2=355375&view=diff
> ==
> --- lldb/trunk/source/Target/Target.cpp (original)
> +++ lldb/trunk/source/Target/Target.cpp Mon Mar  4 19:33:34 2019
> @@ -2401,12 +2401,11 @@ ExpressionResults Target::EvaluateExpres
>   } else {
> llvm::StringRef prefix = GetExpressionPrefixContents();
> Status error;
> -execution_results = UserExpression::Evaluate(exe_ctx, options, expr, 
> prefix,
> - result_valobj_sp, error,
> - 0, // Line Number
> -

Re: [Lldb-commits] [lldb] r355406 - Revert "Fix embedded Python initialization according to changes in version 3.7"

[Stella Stamenova via lldb-commits]

I ran the tests without that line on a machine that is equivalent to the 
Buildbot and they ran correctly, but I just noticed that while the Buildbot has 
had several runs that did not time out since the revert, there was also one 
that did time out.

I am going to let the current build on the Buildbot complete (since it should 
be green as a fix was committed for the other failure) and I'm going to restart 
it afterwards.

In the mean time, I am running the tests on the machine that is the same with 
the full python 3.7 change to confirm whether it hangs there too or if it was 
somehow bot specific.

Thanks,
-Stella

-Original Message-
From: Davide Italiano  
Sent: Tuesday, March 5, 2019 8:43 AM
To: Stella Stamenova 
Cc: Tatyana Krasnukha ; lldb-commits 

Subject: Re: [Lldb-commits] [lldb] r355406 - Revert "Fix embedded Python 
initialization according to changes in version 3.7"

On Tue, Mar 5, 2019 at 8:39 AM Stella Stamenova  wrote:
>
> The bot is running 3.6.6 and it does not have python 3.7 installed (it does 
> have python 2.7 which is needed to run Buildbot).
>
> The change that was pushed, though, did not only impact python 3.7:
>
> m_was_already_initialized == PyGILState_UNLOCKED ? "un" : "");
> m_gil_state == PyGILState_UNLOCKED ? "un" : "");
>
> It replaced m_was_already_initialized above with m_gil_state - for *any* 
> version of python. Yes, this is just in a log, but my guess is that that's 
> the source of the hang on Windows not the 3.7 specific code.
>
> If you end up with a  prototype change that you want to commit, I can run a 
> local test to see whether the tests pass with it.
>

Can you just revert that chunk of unconditional python code and try?
(it's extremely surprising to me that the change caused the bots to hang, even 
if it's unconditional, anyway).

i.e.

+// Since Python 3.7 `Py_Initialize` calls `PyEval_InitThreads` inside 
+itself, // so there is no way to determine whether the embedded 
+interpreter // was already initialized by some external code. 
+`PyEval_ThreadsInitialized` // would always return `true` and 
+`PyGILState_Ensure/Release` flow would be // executed instead of 
+unlocking GIL with `PyEval_SaveThread`. When // an another thread calls 
`PyGILState_Ensure` it would get stuck in deadlock.
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 7) || 
+(PY_MAJOR_VERSION > 3) // The only case we should go further and acquire the 
GIL: it is unlocked.
+if (PyGILState_Check())
+  return;
+#endif
+

and let us know if the bot still hangs?

Thanks,

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

Re: [Lldb-commits] [lldb] r355375 - [Expression] Remove unused parameter from Evaluate

[Jim Ingham via lldb-commits]

Eh, I take that back.  We switched to injecting #file and #line into the body 
text to do the same job, so this is indeed no longer needed.

Jim


> On Mar 5, 2019, at 10:21 AM, Jim Ingham via lldb-commits 
>  wrote:
> 
> If you don't mind, I would like to revert this patch.  Though the parameter 
> is currently unused on the llvm.org side, it is used in the Swift REPL, so 
> removing it causes unnecessary conflicts.  Also, it will be necessary to 
> support any kind of REPL - Sean gave a talk a couple of years ago at the llvm 
> conference about doing a C++ REPL in lldb so this is not entirely 
> speculative... So I'd like to keep it plumbed through.  I can't see that it 
> does any harm.
> 
> Jim
> 
>> On Mar 4, 2019, at 7:33 PM, Alex Langford via lldb-commits 
>>  wrote:
>> 
>> Author: xiaobai
>> Date: Mon Mar  4 19:33:34 2019
>> New Revision: 355375
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=355375&view=rev
>> Log:
>> [Expression] Remove unused parameter from Evaluate
>> 
>> Modified:
>>   lldb/trunk/include/lldb/Expression/UserExpression.h
>>   lldb/trunk/source/Expression/REPL.cpp
>>   lldb/trunk/source/Expression/UserExpression.cpp
>>   lldb/trunk/source/Target/Target.cpp
>> 
>> Modified: lldb/trunk/include/lldb/Expression/UserExpression.h
>> URL: 
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Expression/UserExpression.h?rev=355375&r1=355374&r2=355375&view=diff
>> ==
>> --- lldb/trunk/include/lldb/Expression/UserExpression.h (original)
>> +++ lldb/trunk/include/lldb/Expression/UserExpression.h Mon Mar  4 19:33:34 
>> 2019
>> @@ -261,10 +261,6 @@ public:
>>  /// Filled in with an error in case the expression evaluation
>>  /// fails to parse, run, or evaluated.
>>  ///
>> -  /// @param[in] line_offset
>> -  /// The offset of the first line of the expression from the 
>> "beginning" of
>> -  /// a virtual source file used for error reporting and debug info.
>> -  ///
>>  /// @param[out] fixed_expression
>>  /// If non-nullptr, the fixed expression is copied into the provided
>>  /// string.
>> @@ -290,7 +286,7 @@ public:
>>  Evaluate(ExecutionContext &exe_ctx, const EvaluateExpressionOptions 
>> &options,
>>   llvm::StringRef expr_cstr, llvm::StringRef expr_prefix,
>>   lldb::ValueObjectSP &result_valobj_sp, Status &error,
>> -   uint32_t line_offset = 0, std::string *fixed_expression = 
>> nullptr,
>> +   std::string *fixed_expression = nullptr,
>>   lldb::ModuleSP *jit_module_sp_ptr = nullptr,
>>   ValueObject *ctx_obj = nullptr);
>> 
>> 
>> Modified: lldb/trunk/source/Expression/REPL.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Expression/REPL.cpp?rev=355375&r1=355374&r2=355375&view=diff
>> ==
>> --- lldb/trunk/source/Expression/REPL.cpp (original)
>> +++ lldb/trunk/source/Expression/REPL.cpp Mon Mar  4 19:33:34 2019
>> @@ -307,7 +307,6 @@ void REPL::IOHandlerInputComplete(IOHand
>>  lldb::ExpressionResults execution_results =
>>  UserExpression::Evaluate(exe_ctx, expr_options, code.c_str(),
>>   expr_prefix, result_valobj_sp, error,
>> -   0,   // Line offset
>>   nullptr, // Fixed Expression
>>   &jit_module_sp);
>> 
>> 
>> Modified: lldb/trunk/source/Expression/UserExpression.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Expression/UserExpression.cpp?rev=355375&r1=355374&r2=355375&view=diff
>> ==
>> --- lldb/trunk/source/Expression/UserExpression.cpp (original)
>> +++ lldb/trunk/source/Expression/UserExpression.cpp Mon Mar  4 19:33:34 2019
>> @@ -139,7 +139,7 @@ lldb::addr_t UserExpression::GetObjectPo
>> lldb::ExpressionResults UserExpression::Evaluate(
>>ExecutionContext &exe_ctx, const EvaluateExpressionOptions &options,
>>llvm::StringRef expr, llvm::StringRef prefix,
>> -lldb::ValueObjectSP &result_valobj_sp, Status &error, uint32_t 
>> line_offset,
>> +lldb::ValueObjectSP &result_valobj_sp, Status &error,
>>std::string *fixed_expression, lldb::ModuleSP *jit_module_sp_ptr,
>>ValueObject *ctx_obj) {
>>  Log *log(lldb_private::GetLogIfAnyCategoriesSet(LIBLLDB_LOG_EXPRESSIONS |
>> 
>> Modified: lldb/trunk/source/Target/Target.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/Target.cpp?rev=355375&r1=355374&r2=355375&view=diff
>> ==
>> --- lldb/trunk/source/Target/Target.cpp (original)
>> +++ lldb/trunk/source/Target/Target.cpp Mon Mar  4 19:33:34 2019
>> @@ -2401,12 +2401,11 @@ ExpressionResults Target::EvaluateExpres
>>  } else {
>>llvm::StringRef prefix =

[Lldb-commits] [lldb] r355422 - [DataFormatters] Fix regression in libc++ std::atomic formatter caused by https://reviews.llvm.org/D56913

[Shafik Yaghmour via lldb-commits]

Author: shafik
Date: Tue Mar  5 10:34:35 2019
New Revision: 355422

URL: http://llvm.org/viewvc/llvm-project?rev=355422&view=rev
Log:
[DataFormatters] Fix regression in libc++ std::atomic formatter caused by 
https://reviews.llvm.org/D56913

rdar://problem/48568543

Modified:
lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxAtomic.cpp
lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxAtomic.h

Modified: lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxAtomic.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxAtomic.cpp?rev=355422&r1=355421&r2=355422&view=diff
==
--- lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxAtomic.cpp (original)
+++ lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxAtomic.cpp Tue Mar  5 
10:34:35 2019
@@ -13,13 +13,68 @@ using namespace lldb;
 using namespace lldb_private;
 using namespace lldb_private::formatters;
 
+//
+// We are supporting two versions of libc++ std::atomic
+//
+// Given std::atomic i;
+//
+// The previous version of std::atomic was laid out like this
+//
+// (lldb) frame var -L -R i
+// 0x7ffeefbff9a0: (std::__1::atomic) i = {
+// 0x7ffeefbff9a0:   std::__1::__atomic_base = {
+// 0x7ffeefbff9a0: std::__1::__atomic_base = {
+// 0x7ffeefbff9a0:   __a_ = 5
+//}
+//}
+// }
+//
+// In this case we need to obtain __a_ and the current version is laid out as 
so
+//
+// (lldb) frame var -L -R i
+// 0x7ffeefbff9b0: (std::__1::atomic) i = {
+// 0x7ffeefbff9b0:   std::__1::__atomic_base = {
+// 0x7ffeefbff9b0: std::__1::__atomic_base = {
+// 0x7ffeefbff9b0:   __a_ = {
+// 0x7ffeefbff9b0: std::__1::__cxx_atomic_base_impl = {
+// 0x7ffeefbff9b0:   __a_value = 5
+//}
+//  }
+//   }
+//}
+//}
+//
+// In this case we need to obtain __a_value
+//
+// The below method covers both cases and returns the relevant member as a
+// ValueObjectSP
+//
+ValueObjectSP
+lldb_private::formatters::GetLibCxxAtomicValue(ValueObject &valobj) {
+  ValueObjectSP non_sythetic = valobj.GetNonSyntheticValue();
+  if (!non_sythetic)
+return {};
+
+  ValueObjectSP member__a_ =
+  non_sythetic->GetChildMemberWithName(ConstString("__a_"), true);
+  if (!member__a_)
+return {};
+
+  ValueObjectSP member__a_value =
+  member__a_->GetChildMemberWithName(ConstString("__a_value"), true);
+  if (!member__a_value)
+return member__a_;
+
+  return member__a_value;
+}
+
 bool lldb_private::formatters::LibCxxAtomicSummaryProvider(
 ValueObject &valobj, Stream &stream, const TypeSummaryOptions &options) {
-  static ConstString g___a_("__a_");
 
-  if (ValueObjectSP child = valobj.GetChildMemberWithName(g___a_, true)) {
+  if (ValueObjectSP atomic_value = GetLibCxxAtomicValue(valobj)) {
 std::string summary;
-if (child->GetSummaryAsCString(summary, options) && summary.size() > 0) {
+if (atomic_value->GetSummaryAsCString(summary, options) &&
+summary.size() > 0) {
   stream.Printf("%s", summary.c_str());
   return true;
 }
@@ -59,9 +114,9 @@ lldb_private::formatters::LibcxxStdAtomi
 : SyntheticChildrenFrontEnd(*valobj_sp), m_real_child(nullptr) {}
 
 bool lldb_private::formatters::LibcxxStdAtomicSyntheticFrontEnd::Update() {
-  static ConstString g___a_("__a_");
-
-  m_real_child = m_backend.GetChildMemberWithName(g___a_, true).get();
+  ValueObjectSP atomic_value = GetLibCxxAtomicValue(m_backend);
+  if (atomic_value)
+m_real_child = GetLibCxxAtomicValue(m_backend).get();
 
   return false;
 }

Modified: lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxAtomic.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxAtomic.h?rev=355422&r1=355421&r2=355422&view=diff
==
--- lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxAtomic.h (original)
+++ lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxAtomic.h Tue Mar  5 
10:34:35 2019
@@ -17,6 +17,9 @@
 
 namespace lldb_private {
 namespace formatters {
+
+lldb::ValueObjectSP GetLibCxxAtomicValue(ValueObject &valobj);
+
 bool LibCxxAtomicSummaryProvider(ValueObject &valobj, Stream &stream,
  const TypeSummaryOptions &options);
 


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

Re: [Lldb-commits] [PATCH] D58976: Introduce core2yaml tool

[Jim Ingham via lldb-commits]

Does objdump not read core files?

Jim


> On Mar 5, 2019, at 8:53 AM, Pavel Labath via Phabricator via lldb-commits 
>  wrote:
> 
> labath added a comment.
> 
> In D58976#1418596 , @clayborg wrote:
> 
>> Do we want this in LLVM instead of lldb?
> 
> 
> The thought has crossed my mind, but for that I would have to also move the 
> minidump parser into llvm. It's already pretty standalone, so it shouldn't be 
> a problem technically, but it's not clear to me whether there is any use case 
> for it in llvm. This is a core file format, and I don't know of any other 
> llvm tool/project working with core files.
> 
> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D58976/new/
> 
> https://reviews.llvm.org/D58976
> 
> 
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

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

Re: [Lldb-commits] [PATCH] D58946: [SBAPI] Don't check IsValid in constructor

[Pavel Labath via lldb-commits]

On 05/03/2019 17:58, Jonas Devlieghere wrote:



On Tue, Mar 5, 2019 at 8:41 AM Pavel Labath > wrote:


On 05/03/2019 17:19, Jonas Devlieghere wrote:
 > Sounds good, I’ll make this change before landing, unless you have
 > further comments?
 >
 > On Tue, Mar 5, 2019 at 4:29 AM Pavel Labath via Phabricator
 > mailto:revi...@reviews.llvm.org>
>>
wrote:
 >
 >     labath added a comment.
 >
 >     The copy constructors and assignment operators are very
repetitive.
 >     What would you say to a function like
 >
 >        template
 >        void clone(std::unique_ptr &dest, const
std::unique_ptr &src) {
 >        if (&dest == &src)
 >          return;
 >        if (src)
 >          dest = llvm::make_unique(*src);
 >        else
 >          dest.reset();
 >        }
 >
 >     (and a similar one for shared_ptrs)? Then both copy
constructors and
 >     assignment operators could be just implemented as
`clone(m_whatever,
 >     rhs.m_whatever);`. (Assuming we don't care about pessimizing the
 >     self-assignment case this could even be `m_whatever =
 >     clone(rhs.m_whatever);`)
 >
 >
 >     Repository:
 >        rLLDB LLDB
 >
 >     CHANGES SINCE LAST ACTION
 > https://reviews.llvm.org/D58946/new/
 >
 > https://reviews.llvm.org/D58946
 >
 >

Yeah, that's fine. The only thing I could possibly add is that this
approach depends on not "mirroring" the default constructor, which is
the thing you were trying to the in the original patch, and I don't
think it's right or necessary.


I thought the same yesterday. The difference is the result of always 
being able to create a default object form Python. However, not all SB 
objects have a default construct. Some things are not valid unless they 
are returned by a factory. That's the reason that some objects always 
initialize their opaque pointer, and some don't. The mirroring of the 
default constructor is to retrain this semantic in the copy constructor.


It's not right because I think a copy constructor should make a exact
copy, regardless of what the default constructor of the same object
would create.


I think we agree, but just to be sure: an exact copy of what? The lldb 
object or the lldb_private object?


Whatever is the semantics we want. In the cases that we're talking about 
here, it's the lldb_private object.




And it's not necessary because if the default constructor already
initializes the unique_ptr member (which is the thing you are trying to
mirror), then you should not ever encounter a object with an empty
unique_ptr to copy from.


Yes, if all code paths initialize the opaque pointer and nothing every 
unsets it, then this is true. Then we can also remove all the spurious 
if(opaque_ptr) checks. But what about classes that don't initialize 
their unique pointer, they still need to be copyable.


That's fine, and in that case you copy the empty pointer as an empty 
pointer. My point is the copy operation should be defined in terms of 
what is the state of the source object, not in terms of what the default 
constructor does. The default constructor is just one way to initialize 
the object, but it's possible that the unique_ptr became uninitialized 
in a different way too.


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

[Lldb-commits] [PATCH] D58630: [lldb] [test] Pass appropriate -L&-Wl, -rpath for libc++ on NetBSD

[Michał Górny via Phabricator via lldb-commits]

mgorny updated this revision to Diff 189364.
mgorny retitled this revision from "[lldb] [test] Pass appropriate 
-L&-Wl,-rpath for just-built libc++" to "[lldb] [test] Pass appropriate 
-L&-Wl,-rpath for libc++ on NetBSD".
mgorny edited the summary of this revision.
mgorny added a comment.

Updated to make it all conditional to NetBSD, as discussed.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58630/new/

https://reviews.llvm.org/D58630

Files:
  lldb/lit/BuildScript/toolchain-clang.test
  lldb/lit/Suite/lit.cfg
  lldb/lit/helper/build.py
  lldb/lit/helper/toolchain.py
  lldb/packages/Python/lldbsuite/test/make/Makefile.rules

Index: lldb/packages/Python/lldbsuite/test/make/Makefile.rules
===
--- lldb/packages/Python/lldbsuite/test/make/Makefile.rules
+++ lldb/packages/Python/lldbsuite/test/make/Makefile.rules
@@ -297,6 +297,11 @@
 LD = $(CC)
 LDFLAGS ?= $(CFLAGS)
 LDFLAGS += $(LD_EXTRAS) $(ARCH_LDFLAGS)
+ifneq (,$(LLVM_LIBS_DIR))
+	ifeq ($(OS),NetBSD)
+		LDFLAGS += -L$(LLVM_LIBS_DIR) -Wl,-rpath,$(LLVM_LIBS_DIR)
+	endif
+endif
 ifeq (,$(filter $(OS), Windows_NT Android Darwin))
 	ifneq (,$(filter YES,$(ENABLE_THREADS)))
 		LDFLAGS += -pthread
Index: lldb/lit/helper/toolchain.py
===
--- lldb/lit/helper/toolchain.py
+++ lldb/lit/helper/toolchain.py
@@ -31,6 +31,8 @@
 build_script_args.append('--tools-dir={0}'.format(config.lldb_lit_tools_dir))
 if config.lldb_tools_dir:
 build_script_args.append('--tools-dir={0}'.format(config.lldb_tools_dir))
+if config.llvm_libs_dir:
+build_script_args.append('--libs-dir={0}'.format(config.llvm_libs_dir))
 
 primary_tools = [
 ToolSubst('%lldb',
@@ -99,6 +101,10 @@
 elif platform.system() in ['OpenBSD', 'Linux']:
 flags = ['-pthread']
 
+if sys.platform.startswith('netbsd'):
+# needed e.g. to use freshly built libc++
+flags += ['-L' + config.llvm_libs_dir,
+  '-Wl,-rpath,' + config.llvm_libs_dir]
 
 additional_tool_dirs=[]
 if config.lldb_lit_tools_dir:
Index: lldb/lit/helper/build.py
===
--- lldb/lit/helper/build.py
+++ lldb/lit/helper/build.py
@@ -35,6 +35,13 @@
 required=True,
 help='Path to a compiler executable, or one of the values [any, msvc, clang-cl, gcc, clang]')
 
+parser.add_argument('--libs-dir',
+metavar='directory',
+dest='libs_dir',
+required=False,
+action='append',
+help='If specified, a path to linked libraries to be passed via -L')
+
 parser.add_argument('--tools-dir',
 metavar='directory',
 dest='tools_dir',
@@ -225,6 +232,7 @@
 self.nodefaultlib = args.nodefaultlib
 self.verbose = args.verbose
 self.obj_ext = obj_ext
+self.lib_paths = args.libs_dir
 
 def _exe_file_name(self):
 assert self.mode != 'compile'
@@ -648,6 +656,9 @@
 if sys.platform == 'darwin':
 main_symbol = '_main'
 args.append('-Wl,-e,' + main_symbol)
+if sys.platform.startswith('netbsd'):
+for x in self.lib_paths:
+args += ['-L' + x, '-Wl,-rpath,' + x]
 args.extend(['-o', self._exe_file_name()])
 args.extend(self._obj_file_names())
 
Index: lldb/lit/Suite/lit.cfg
===
--- lldb/lit/Suite/lit.cfg
+++ lldb/lit/Suite/lit.cfg
@@ -42,6 +42,10 @@
 if config.dotest_lit_args_str:
   dotest_cmd.extend(shlex.split(config.dotest_lit_args_str))
 
+# Library path may be needed to locate just-built clang.
+if config.llvm_libs_dir:
+  dotest_cmd += ['--env', 'LLVM_LIBS_DIR=' + config.llvm_libs_dir]
+
 # Load LLDB test format.
 sys.path.append(os.path.join(config.lldb_src_root, "lit", "Suite"))
 import lldbtest
Index: lldb/lit/BuildScript/toolchain-clang.test
===
--- lldb/lit/BuildScript/toolchain-clang.test
+++ lldb/lit/BuildScript/toolchain-clang.test
@@ -10,5 +10,5 @@
 CHECK-32: {{.*}}clang++{{(.exe)?}} -m32 -g -O0 -c -o {{.*}}foo.exe-foobar.o {{.*}}foobar.c
 CHECK-64: {{.*}}clang++{{(.exe)?}} -m64 -g -O0 -c -o {{.*}}foo.exe-foobar.o {{.*}}foobar.c
 CHECK: linking foo.exe-foobar.o -> foo.exe
-CHECK-32: {{.*}}clang++{{(.exe)?}} -m32 -o {{.*}}foo.exe {{.*}}foo.exe-foobar.o
-CHECK-64: {{.*}}clang++{{(.exe)?}} -m64 -o {{.*}}foo.exe {{.*}}foo.exe-foobar.o
+CHECK-32: {{.*}}clang++{{(.exe)?}} -m32 {{(-L.*)? (-Wl,-rpath,.*)?}} -o {{.*}}foo.exe {{.*}}foo.exe-foobar.o
+CHECK-64: {{.*}}clang++{{(.exe)?}} -m64 {{(-L.*)? (-Wl,-rpath,.*)?}} -o {{.*}}foo.exe {{.*}}foo.exe-foobar.o
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
h

[Lldb-commits] [PATCH] D58985: Fix core files for 32 bit architectures that are supported in ProcessELFCore.cpp

[Greg Clayton via Phabricator via lldb-commits]

clayborg created this revision.
clayborg added reviewers: labath, hhellyer, omjavaid, tberghammer.
Herald added subscribers: kristof.beyls, javed.absar.
Herald added a reviewer: serge-sans-paille.

Core files need to know the size of the PRSTATUS header so that we can grab the 
register values that follow it. The code that figure out this size was using a 
hard coded list of architecture cores instead of relying on 32 or 64 bit for 
most cores.

The fix here fixes core files for 32 bit ARM. Prior to this the PRSTATUS header 
size was being returned as zero and the register values were being taken from 
the first bytes of the PRSTATUS struct (signo, etc).


https://reviews.llvm.org/D58985

Files:
  
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/TestLinuxCore.py
  
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/linux-arm.core
  source/Plugins/Process/elf-core/ThreadElfCore.cpp


Index: source/Plugins/Process/elf-core/ThreadElfCore.cpp
===
--- source/Plugins/Process/elf-core/ThreadElfCore.cpp
+++ source/Plugins/Process/elf-core/ThreadElfCore.cpp
@@ -266,15 +266,14 @@
 return mips_linux_pr_status_size_n32;
   }
   switch (arch.GetCore()) {
-  case lldb_private::ArchSpec::eCore_s390x_generic:
-  case lldb_private::ArchSpec::eCore_x86_64_x86_64:
-  case lldb_private::ArchSpec::eCore_ppc64le_generic:
-return sizeof(ELFLinuxPrStatus);
   case lldb_private::ArchSpec::eCore_x86_32_i386:
   case lldb_private::ArchSpec::eCore_x86_32_i486:
 return 72;
   default:
-return 0;
+if (arch.GetAddressByteSize() == 8)
+  return sizeof(ELFLinuxPrStatus);
+else
+  return sizeof(ELFLinuxPrStatus) - 10 * 4;
   }
 }
 
Index: 
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/TestLinuxCore.py
===
--- 
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/TestLinuxCore.py
+++ 
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/TestLinuxCore.py
@@ -217,6 +217,35 @@
 
 self.dbg.DeleteTarget(target)
 
+@skipIf(triple='^mips')
+@skipIfLLVMTargetMissing("ARM")
+def test_arm_core(self):
+# check 32 bit ARM core file
+target = self.dbg.CreateTarget(None)
+self.assertTrue(target, VALID_TARGET)
+process = target.LoadCore("linux-arm.core")
+
+values = {}
+values["r0"] = "0x"
+values["r1"] = "0x0001"
+values["r2"] = "0x0002"
+values["r3"] = "0x0003"
+values["r4"] = "0x0004"
+values["r5"] = "0x0005"
+values["r6"] = "0x0006"
+values["r7"] = "0x0007"
+values["r8"] = "0x0008"
+values["r9"] = "0x0009"
+values["r10"] = "0x000a"
+values["r11"] = "0x000b"
+values["r12"] = "0x000c"
+values["sp"] = "0x000d"
+values["lr"] = "0x000e"
+values["pc"] = "0x000f"
+values["cpsr"] = "0x0010"
+for regname, value in values.items():
+self.expect("register read {}".format(regname), substrs=["{} = 
{}".format(regname, value)])
+
 def check_memory_regions(self, process, region_count):
 region_list = process.GetMemoryRegions()
 self.assertEqual(region_list.GetSize(), region_count)


Index: source/Plugins/Process/elf-core/ThreadElfCore.cpp
===
--- source/Plugins/Process/elf-core/ThreadElfCore.cpp
+++ source/Plugins/Process/elf-core/ThreadElfCore.cpp
@@ -266,15 +266,14 @@
 return mips_linux_pr_status_size_n32;
   }
   switch (arch.GetCore()) {
-  case lldb_private::ArchSpec::eCore_s390x_generic:
-  case lldb_private::ArchSpec::eCore_x86_64_x86_64:
-  case lldb_private::ArchSpec::eCore_ppc64le_generic:
-return sizeof(ELFLinuxPrStatus);
   case lldb_private::ArchSpec::eCore_x86_32_i386:
   case lldb_private::ArchSpec::eCore_x86_32_i486:
 return 72;
   default:
-return 0;
+if (arch.GetAddressByteSize() == 8)
+  return sizeof(ELFLinuxPrStatus);
+else
+  return sizeof(ELFLinuxPrStatus) - 10 * 4;
   }
 }
 
Index: packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/TestLinuxCore.py
===
--- packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/TestLinuxCore.py
+++ packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/TestLinuxCore.py
@@ -217,6 +217,35 @@
 
 self.dbg.DeleteTarget(target)
 
+@skipIf(triple='^mips')
+@skipIfLLVMTargetMissing("ARM")
+def test_arm_core(self):
+# check 32 bit ARM core file
+target = self.dbg.CreateTarget(None)
+self.assertTrue(target, VALID_TARGET)
+process = target.LoadCore("linux-arm.core")
+
+values = {}
+values["r0"] = "0x"
+   

[Lldb-commits] [PATCH] D58972: Introduce the "Formats" module and move LinuxProcMaps parser to it

[Zachary Turner via Phabricator via lldb-commits]

zturner accepted this revision.
zturner added a comment.
This revision is now accepted and ready to land.

Great idea, this is a nice analogue to LLVM/BinaryFormat.

But, "Formats" is a little generic.  What about FileFormats or something?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58972/new/

https://reviews.llvm.org/D58972



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

[Lldb-commits] [PATCH] D58971: Move MemoryRegionInfo into the Utility module

[Zachary Turner via Phabricator via lldb-commits]

zturner added a comment.

One idea for a new module name could be `AbstractProcess`, but I can't think of 
anything else better at the moment.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58971/new/

https://reviews.llvm.org/D58971



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

[Lldb-commits] [PATCH] D58985: Fix core files for 32 bit architectures that are supported in ProcessELFCore.cpp

[Zachary Turner via Phabricator via lldb-commits]

zturner added inline comments.



Comment at: source/Plugins/Process/elf-core/ThreadElfCore.cpp:276
+else
+  return sizeof(ELFLinuxPrStatus) - 10 * 4;
   }

subtracting 40 from the header size seems a bit magical to those not in the 
know (such as myself).  Could you do something like:

```
if (arch.GetAddressByteSize() == 8)
return sizeof(ELFLinuxPrStatus);

lldbassert(arch.GetAddressByteSize() == 4);
constexpr int kWhatever = 10;
return sizeof(ELFLinuxPrStatus) - kWhatever * arch.GetAddressByteSize();
```


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58985/new/

https://reviews.llvm.org/D58985



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

[Lldb-commits] [PATCH] D58985: Fix core files for 32 bit architectures that are supported in ProcessELFCore.cpp

[Greg Clayton via Phabricator via lldb-commits]

clayborg updated this revision to Diff 189374.
clayborg added a comment.

Fix zturner's suggestion.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58985/new/

https://reviews.llvm.org/D58985

Files:
  
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/TestLinuxCore.py
  
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/linux-arm.core
  source/Plugins/Process/elf-core/ThreadElfCore.cpp


Index: source/Plugins/Process/elf-core/ThreadElfCore.cpp
===
--- source/Plugins/Process/elf-core/ThreadElfCore.cpp
+++ source/Plugins/Process/elf-core/ThreadElfCore.cpp
@@ -255,6 +255,7 @@
 size_t ELFLinuxPrStatus::GetSize(const lldb_private::ArchSpec &arch) {
   constexpr size_t mips_linux_pr_status_size_o32 = 96;
   constexpr size_t mips_linux_pr_status_size_n32 = 72;
+  constexpr size_t num_ptr_size_members = 10;
   if (arch.IsMIPS()) {
 std::string abi = arch.GetTargetABI();
 assert(!abi.empty() && "ABI is not set");
@@ -266,15 +267,14 @@
 return mips_linux_pr_status_size_n32;
   }
   switch (arch.GetCore()) {
-  case lldb_private::ArchSpec::eCore_s390x_generic:
-  case lldb_private::ArchSpec::eCore_x86_64_x86_64:
-  case lldb_private::ArchSpec::eCore_ppc64le_generic:
-return sizeof(ELFLinuxPrStatus);
   case lldb_private::ArchSpec::eCore_x86_32_i386:
   case lldb_private::ArchSpec::eCore_x86_32_i486:
 return 72;
   default:
-return 0;
+if (arch.GetAddressByteSize() == 8)
+  return sizeof(ELFLinuxPrStatus);
+else
+  return sizeof(ELFLinuxPrStatus) - num_ptr_size_members * 4;
   }
 }
 
Index: 
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/TestLinuxCore.py
===
--- 
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/TestLinuxCore.py
+++ 
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/TestLinuxCore.py
@@ -217,6 +217,35 @@
 
 self.dbg.DeleteTarget(target)
 
+@skipIf(triple='^mips')
+@skipIfLLVMTargetMissing("ARM")
+def test_arm_core(self):
+# check 32 bit ARM core file
+target = self.dbg.CreateTarget(None)
+self.assertTrue(target, VALID_TARGET)
+process = target.LoadCore("linux-arm.core")
+
+values = {}
+values["r0"] = "0x"
+values["r1"] = "0x0001"
+values["r2"] = "0x0002"
+values["r3"] = "0x0003"
+values["r4"] = "0x0004"
+values["r5"] = "0x0005"
+values["r6"] = "0x0006"
+values["r7"] = "0x0007"
+values["r8"] = "0x0008"
+values["r9"] = "0x0009"
+values["r10"] = "0x000a"
+values["r11"] = "0x000b"
+values["r12"] = "0x000c"
+values["sp"] = "0x000d"
+values["lr"] = "0x000e"
+values["pc"] = "0x000f"
+values["cpsr"] = "0x0010"
+for regname, value in values.items():
+self.expect("register read {}".format(regname), substrs=["{} = 
{}".format(regname, value)])
+
 def check_memory_regions(self, process, region_count):
 region_list = process.GetMemoryRegions()
 self.assertEqual(region_list.GetSize(), region_count)


Index: source/Plugins/Process/elf-core/ThreadElfCore.cpp
===
--- source/Plugins/Process/elf-core/ThreadElfCore.cpp
+++ source/Plugins/Process/elf-core/ThreadElfCore.cpp
@@ -255,6 +255,7 @@
 size_t ELFLinuxPrStatus::GetSize(const lldb_private::ArchSpec &arch) {
   constexpr size_t mips_linux_pr_status_size_o32 = 96;
   constexpr size_t mips_linux_pr_status_size_n32 = 72;
+  constexpr size_t num_ptr_size_members = 10;
   if (arch.IsMIPS()) {
 std::string abi = arch.GetTargetABI();
 assert(!abi.empty() && "ABI is not set");
@@ -266,15 +267,14 @@
 return mips_linux_pr_status_size_n32;
   }
   switch (arch.GetCore()) {
-  case lldb_private::ArchSpec::eCore_s390x_generic:
-  case lldb_private::ArchSpec::eCore_x86_64_x86_64:
-  case lldb_private::ArchSpec::eCore_ppc64le_generic:
-return sizeof(ELFLinuxPrStatus);
   case lldb_private::ArchSpec::eCore_x86_32_i386:
   case lldb_private::ArchSpec::eCore_x86_32_i486:
 return 72;
   default:
-return 0;
+if (arch.GetAddressByteSize() == 8)
+  return sizeof(ELFLinuxPrStatus);
+else
+  return sizeof(ELFLinuxPrStatus) - num_ptr_size_members * 4;
   }
 }
 
Index: packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/TestLinuxCore.py
===
--- packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/TestLinuxCore.py
+++ packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/TestLinuxCore.py
@@ -217,6 +217,35 @@
 
 self.dbg.DeleteTarget(target)
 
+@skipIf(triple='^mips')
+@skipIfLLVMTargetMissing("ARM")
+def te

[Lldb-commits] [PATCH] D58946: [SBAPI] Don't check IsValid in constructor

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere updated this revision to Diff 189377.
JDevlieghere added a comment.

- Add clone utility.
- Updated other SB classes to make use of the clone function as well.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58946/new/

https://reviews.llvm.org/D58946

Files:
  lldb/source/API/SBAddress.cpp
  lldb/source/API/SBAttachInfo.cpp
  lldb/source/API/SBCommandReturnObject.cpp
  lldb/source/API/SBDeclaration.cpp
  lldb/source/API/SBError.cpp
  lldb/source/API/SBExpressionOptions.cpp
  lldb/source/API/SBFileSpec.cpp
  lldb/source/API/SBFileSpecList.cpp
  lldb/source/API/SBFrame.cpp
  lldb/source/API/SBLineEntry.cpp
  lldb/source/API/SBMemoryRegionInfo.cpp
  lldb/source/API/SBModuleSpec.cpp
  lldb/source/API/SBProcessInfo.cpp
  lldb/source/API/SBStringList.cpp
  lldb/source/API/SBSymbolContext.cpp
  lldb/source/API/SBSymbolContextList.cpp
  lldb/source/API/SBThread.cpp
  lldb/source/API/SBTypeEnumMember.cpp
  lldb/source/API/SBTypeSummary.cpp
  lldb/source/API/Utils.h

Index: lldb/source/API/Utils.h
===
--- /dev/null
+++ lldb/source/API/Utils.h
@@ -0,0 +1,30 @@
+//===-- Utils.h -*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_API_UTILS_H
+#define LLDB_API_UTILS_H
+
+#include "llvm/ADT/STLExtras.h"
+#include 
+
+namespace lldb_private {
+
+template  std::unique_ptr clone(const std::unique_ptr &src) {
+  if (src)
+return llvm::make_unique(*src);
+  return nullptr;
+}
+
+template  std::shared_ptr clone(const std::shared_ptr &src) {
+  if (src)
+return std::make_shared(*src);
+  return nullptr;
+}
+
+} // namespace lldb_private
+#endif
Index: lldb/source/API/SBTypeSummary.cpp
===
--- lldb/source/API/SBTypeSummary.cpp
+++ lldb/source/API/SBTypeSummary.cpp
@@ -8,6 +8,7 @@
 //===--===//
 
 #include "lldb/API/SBTypeSummary.h"
+#include "Utils.h"
 #include "lldb/API/SBStream.h"
 #include "lldb/API/SBValue.h"
 #include "lldb/DataFormatters/DataVisualization.h"
@@ -17,16 +18,12 @@
 using namespace lldb;
 using namespace lldb_private;
 
-SBTypeSummaryOptions::SBTypeSummaryOptions() {
-  m_opaque_up.reset(new TypeSummaryOptions());
-}
+SBTypeSummaryOptions::SBTypeSummaryOptions()
+: m_opaque_up(new TypeSummaryOptions()) {}
 
 SBTypeSummaryOptions::SBTypeSummaryOptions(
 const lldb::SBTypeSummaryOptions &rhs) {
-  if (rhs.m_opaque_up)
-m_opaque_up.reset(new TypeSummaryOptions(*rhs.m_opaque_up));
-  else
-m_opaque_up.reset(new TypeSummaryOptions());
+  m_opaque_up = clone(rhs.m_opaque_up);
 }
 
 SBTypeSummaryOptions::~SBTypeSummaryOptions() {}
Index: lldb/source/API/SBTypeEnumMember.cpp
===
--- lldb/source/API/SBTypeEnumMember.cpp
+++ lldb/source/API/SBTypeEnumMember.cpp
@@ -7,6 +7,7 @@
 //===--===//
 
 #include "lldb/API/SBTypeEnumMember.h"
+#include "Utils.h"
 #include "lldb/API/SBDefines.h"
 #include "lldb/API/SBStream.h"
 #include "lldb/API/SBType.h"
@@ -22,23 +23,19 @@
 SBTypeEnumMember::SBTypeEnumMember() : m_opaque_sp() {}
 
 SBTypeEnumMember::~SBTypeEnumMember() {}
+
 SBTypeEnumMember::SBTypeEnumMember(
 const lldb::TypeEnumMemberImplSP &enum_member_sp)
 : m_opaque_sp(enum_member_sp) {}
 
 SBTypeEnumMember::SBTypeEnumMember(const SBTypeEnumMember &rhs)
 : m_opaque_sp() {
-  if (this != &rhs) {
-if (rhs.IsValid())
-  m_opaque_sp = std::make_shared(rhs.ref());
-  }
+  m_opaque_sp = clone(rhs.m_opaque_sp);
 }
 
 SBTypeEnumMember &SBTypeEnumMember::operator=(const SBTypeEnumMember &rhs) {
-  if (this != &rhs) {
-if (rhs.IsValid())
-  m_opaque_sp = std::make_shared(rhs.ref());
-  }
+  if (this != &rhs)
+m_opaque_sp = clone(rhs.m_opaque_sp);
   return *this;
 }
 
Index: lldb/source/API/SBThread.cpp
===
--- lldb/source/API/SBThread.cpp
+++ lldb/source/API/SBThread.cpp
@@ -8,6 +8,7 @@
 
 #include "lldb/API/SBThread.h"
 
+#include "Utils.h"
 #include "lldb/API/SBFileSpec.h"
 #include "lldb/API/SBStream.h"
 #include "lldb/API/SBSymbolContext.h"
@@ -61,8 +62,9 @@
 SBThread::SBThread(const ThreadSP &lldb_object_sp)
 : m_opaque_sp(new ExecutionContextRef(lldb_object_sp)) {}
 
-SBThread::SBThread(const SBThread &rhs)
-: m_opaque_sp(new ExecutionContextRef(*rhs.m_opaque_sp)) {}
+SBThread::SBThread(const SBThread &rhs) : m_opaque_sp() {
+  m_opaque_sp = clone(rhs.m_opaque_sp);
+}
 
 //

[Lldb-commits] [PATCH] D58930: Add XCOFF triple object format type for AIX

[Jason Liu via Phabricator via lldb-commits]

jasonliu marked 2 inline comments as done.
jasonliu added inline comments.



Comment at: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp:2079
+  if (log)
+log->Printf("sorry: unimplemented for XCOFF");
+  return false;

apaprocki wrote:
> No need to be `sorry:` :) This should probably just say `error: XCOFF is 
> unimplemented` to be more direct in case anything is expecting "error:" in 
> the output.
Sure. Will address in next revision.



Comment at: llvm/lib/Support/Triple.cpp:537
   return StringSwitch(EnvironmentName)
+// FIXME: We have to put XCOFF before COFF;
+// perhaps an order-independent pattern matching is desired?

apaprocki wrote:
> hubert.reinterpretcast wrote:
> > If the conclusion is that checking XCOFF before COFF is fine, then we 
> > should remove the FIXME and just leave a normal comment.
> Agreed, existing code seems fine as long as there is a comment explaining 
> that `xcoff` must come before `coff` in case it isn't obvious at a quick 
> glance.
Sounds good. I will remove FIXME and leave a normal comment to indicate the 
order dependency. 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58930/new/

https://reviews.llvm.org/D58930



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

[Lldb-commits] [lldb] r355435 - Add logging to SBCompileUnit::GetNumLineEntries.

[Jason Molenda via lldb-commits]

Author: jmolenda
Date: Tue Mar  5 11:43:56 2019
New Revision: 355435

URL: http://llvm.org/viewvc/llvm-project?rev=355435&view=rev
Log:
Add logging to SBCompileUnit::GetNumLineEntries.

Modified:
lldb/trunk/source/API/SBCompileUnit.cpp

Modified: lldb/trunk/source/API/SBCompileUnit.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/API/SBCompileUnit.cpp?rev=355435&r1=355434&r2=355435&view=diff
==
--- lldb/trunk/source/API/SBCompileUnit.cpp (original)
+++ lldb/trunk/source/API/SBCompileUnit.cpp Tue Mar  5 11:43:56 2019
@@ -43,10 +43,15 @@ SBFileSpec SBCompileUnit::GetFileSpec()
 }
 
 uint32_t SBCompileUnit::GetNumLineEntries() const {
+  Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_API));
   if (m_opaque_ptr) {
 LineTable *line_table = m_opaque_ptr->GetLineTable();
-if (line_table)
+if (line_table) {
+  log->Printf("SBCompileUnit(%p)::GetNumLineEntries() => %d",
+static_cast(m_opaque_ptr), 
+(int)line_table->GetSize());
   return line_table->GetSize();
+}
   }
   return 0;
 }


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

[Lldb-commits] [PATCH] D58748: [ExpressionParser] Test GetClangResourceDir

[Alex Langford via Phabricator via lldb-commits]

xiaobai added a comment.

@aprantl: Do you mind taking a look at this when you get a moment?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58748/new/

https://reviews.llvm.org/D58748



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

[Lldb-commits] [PATCH] D58972: Introduce the "Formats" module and move LinuxProcMaps parser to it

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

FileFormats wouldn't be generic enough to capture the gdb-remote or 
debug-info-server protocol code. However, even calling gdb-remote protocol a 
"format" is still a bit of a stretch. I think there is enough similarity 
between gdb-remote and minidump code for them to be in the same module (both 
convert some (and often the same) data structures into some (file or wire) 
format), but they're also sufficiently different for them to live in different 
places. So yeah, if we want the protocol code to live in a different library 
(Protocols ?), then FileFormats is a better name here.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58972/new/

https://reviews.llvm.org/D58972



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

[Lldb-commits] [PATCH] D58748: [ExpressionParser] Test GetClangResourceDir

[Adrian Prantl via Phabricator via lldb-commits]

aprantl added a comment.

Looks mostly good!




Comment at: source/Plugins/ExpressionParser/Clang/ClangHost.cpp:45
 
+static bool DefaultComputeClangDirectory(FileSpec &lldb_shlib_spec,
+ FileSpec &file_spec, bool verify) {

While you are at it, could you rename this 
`DefaultComputeClangResourceDirectory`?
And add a doxygen comment that says it will compute the calng resource 
directory assuming that clang was installed to the same prefix as lldb?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58748/new/

https://reviews.llvm.org/D58748



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

Re: [Lldb-commits] [PATCH] D58972: Introduce the "Formats" module and move LinuxProcMaps parser to it

[Zachary Turner via lldb-commits]

How about SerializationFormats?
On Tue, Mar 5, 2019 at 12:22 PM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:

> labath added a comment.
>
> FileFormats wouldn't be generic enough to capture the gdb-remote or
> debug-info-server protocol code. However, even calling gdb-remote protocol
> a "format" is still a bit of a stretch. I think there is enough similarity
> between gdb-remote and minidump code for them to be in the same module
> (both convert some (and often the same) data structures into some (file or
> wire) format), but they're also sufficiently different for them to live in
> different places. So yeah, if we want the protocol code to live in a
> different library (Protocols ?), then FileFormats is a better name here.
>
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D58972/new/
>
> https://reviews.llvm.org/D58972
>
>
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D58930: Add XCOFF triple object format type for AIX

[Jason Liu via Phabricator via lldb-commits]

jasonliu updated this revision to Diff 189387.
jasonliu added a comment.

Address some review comments


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58930/new/

https://reviews.llvm.org/D58930

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
  llvm/include/llvm/ADT/Triple.h
  llvm/include/llvm/MC/MCObjectFileInfo.h
  llvm/lib/MC/MCContext.cpp
  llvm/lib/MC/MCObjectFileInfo.cpp
  llvm/lib/MC/MCParser/AsmParser.cpp
  llvm/lib/Support/Triple.cpp
  llvm/lib/Target/ARM/AsmParser/ARMAsmParser.cpp
  llvm/unittests/ADT/TripleTest.cpp

Index: llvm/unittests/ADT/TripleTest.cpp
===
--- llvm/unittests/ADT/TripleTest.cpp
+++ llvm/unittests/ADT/TripleTest.cpp
@@ -1258,6 +1258,11 @@
   EXPECT_EQ(Triple::Wasm,
 Triple("wasm64-unknown-wasi-musl-wasm").getObjectFormat());
 
+  EXPECT_EQ(Triple::XCOFF, Triple("powerpc-ibm-aix").getObjectFormat());
+  EXPECT_EQ(Triple::XCOFF, Triple("powerpc64-ibm-aix").getObjectFormat());
+  EXPECT_EQ(Triple::XCOFF, Triple("powerpc---xcoff").getObjectFormat());
+  EXPECT_EQ(Triple::XCOFF, Triple("powerpc64---xcoff").getObjectFormat());
+
   Triple MSVCNormalized(Triple::normalize("i686-pc-windows-msvc-elf"));
   EXPECT_EQ(Triple::ELF, MSVCNormalized.getObjectFormat());
 
@@ -1276,6 +1281,9 @@
 
   T.setObjectFormat(Triple::MachO);
   EXPECT_EQ(Triple::MachO, T.getObjectFormat());
+  
+  T.setObjectFormat(Triple::XCOFF);
+  EXPECT_EQ(Triple::XCOFF, T.getObjectFormat());
 }
 
 TEST(TripleTest, NormalizeWindows) {
Index: llvm/lib/Target/ARM/AsmParser/ARMAsmParser.cpp
===
--- llvm/lib/Target/ARM/AsmParser/ARMAsmParser.cpp
+++ llvm/lib/Target/ARM/AsmParser/ARMAsmParser.cpp
@@ -5594,6 +5594,9 @@
   case MCObjectFileInfo::IsWasm:
 CurrentFormat = WASM;
 break;
+  case MCObjectFileInfo::IsXCOFF:
+llvm_unreachable("unexpected object format");
+break;
   }
 
   if (~Prefix->SupportedFormats & CurrentFormat) {
Index: llvm/lib/Support/Triple.cpp
===
--- llvm/lib/Support/Triple.cpp
+++ llvm/lib/Support/Triple.cpp
@@ -534,6 +534,9 @@
 
 static Triple::ObjectFormatType parseFormat(StringRef EnvironmentName) {
   return StringSwitch(EnvironmentName)
+// "xcoff" must come before "coff" because of the order-dependendent
+// pattern matching.
+.EndsWith("xcoff", Triple::XCOFF)
 .EndsWith("coff", Triple::COFF)
 .EndsWith("elf", Triple::ELF)
 .EndsWith("macho", Triple::MachO)
@@ -622,6 +625,7 @@
   case Triple::ELF: return "elf";
   case Triple::MachO: return "macho";
   case Triple::Wasm: return "wasm";
+  case Triple::XCOFF: return "xcoff";
   }
   llvm_unreachable("unknown object format type");
 }
@@ -686,6 +690,8 @@
   case Triple::ppc64:
 if (T.isOSDarwin())
   return Triple::MachO;
+else if (T.isOSAIX())
+  return Triple::XCOFF;
 return Triple::ELF;
 
   case Triple::wasm32:
Index: llvm/lib/MC/MCParser/AsmParser.cpp
===
--- llvm/lib/MC/MCParser/AsmParser.cpp
+++ llvm/lib/MC/MCParser/AsmParser.cpp
@@ -710,6 +710,9 @@
   case MCObjectFileInfo::IsWasm:
 PlatformParser.reset(createWasmAsmParser());
 break;
+  case MCObjectFileInfo::IsXCOFF:
+// TODO: Need to implement createXCOFFAsmParser for XCOFF format.
+break;
   }
 
   PlatformParser->Initialize(*this);
Index: llvm/lib/MC/MCObjectFileInfo.cpp
===
--- llvm/lib/MC/MCObjectFileInfo.cpp
+++ llvm/lib/MC/MCObjectFileInfo.cpp
@@ -801,6 +801,10 @@
 Env = IsWasm;
 initWasmMCObjectFileInfo(TT);
 break;
+  case Triple::XCOFF:
+Env = IsXCOFF;
+// TODO: Initialize MCObjectFileInfo for XCOFF format when MCSectionXCOFF is ready.
+break;
   case Triple::UnknownObjectFormat:
 report_fatal_error("Cannot initialize MC for unknown object file format.");
 break;
@@ -816,6 +820,7 @@
   case Triple::MachO:
   case Triple::COFF:
   case Triple::Wasm:
+  case Triple::XCOFF:
   case Triple::UnknownObjectFormat:
 report_fatal_error("Cannot get DWARF comdat section for this object file "
"format: not implemented.");
Index: llvm/lib/MC/MCContext.cpp
===
--- llvm/lib/MC/MCContext.cpp
+++ llvm/lib/MC/MCContext.cpp
@@ -161,6 +161,9 @@
   return new (Name, *this) MCSymbolMachO(Name, IsTemporary);
 case MCObjectFileInfo::IsWasm:
   return new (Name, *this) MCSymbolWasm(Name, IsTemporary);
+case MCObjectFileInfo::IsXCOFF:
+  // TODO: Need to implement class MCSymbolXCOFF.
+  break;
 }
   }
   return new (Name, *this) MCSymbol(MCSymbol::SymbolKindUnset, Name,
Index: llvm/include/llvm/MC/M

[Lldb-commits] [PATCH] D58930: Add XCOFF triple object format type for AIX

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere requested changes to this revision.
JDevlieghere added inline comments.
This revision now requires changes to proceed.



Comment at: clang/lib/CodeGen/BackendUtil.cpp:1470
+  case Triple::XCOFF:
+// TODO: Falling through for XCOFF format for now.
+break;

This is confusing, you say fall through but you break? I would prefer a 
`llvm_unreachable("XCOFF not yet implemented");` here and elsewhere in this 
patch. 




Comment at: clang/lib/CodeGen/BackendUtil.cpp:1486
+  case Triple::XCOFF:
+// TODO: Falling through for XCOFF format for now.
+break;

See previous comment.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:4410
+  case llvm::Triple::XCOFF:
+llvm_unreachable("to be determined for XCOFF format");
   case llvm::Triple::COFF:

See previous comment.



Comment at: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp:2079
+  if (log)
+log->Printf("sorry: unimplemented for XCOFF");
+  return false;

jasonliu wrote:
> apaprocki wrote:
> > No need to be `sorry:` :) This should probably just say `error: XCOFF is 
> > unimplemented` to be more direct in case anything is expecting "error:" in 
> > the output.
> Sure. Will address in next revision.
Just bundle this with the WASM case, the error message is correct for both.



Comment at: llvm/lib/MC/MCContext.cpp:165
+case MCObjectFileInfo::IsXCOFF:
+  // TODO: Need to implement class MCSymbolXCOFF.
+  break;

See previous comment.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58930/new/

https://reviews.llvm.org/D58930



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

[Lldb-commits] [PATCH] D58930: Add XCOFF triple object format type for AIX

[Jason Liu via Phabricator via lldb-commits]

jasonliu marked an inline comment as done.
jasonliu added inline comments.



Comment at: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp:2079
+  if (log)
+log->Printf("sorry: unimplemented for XCOFF");
+  return false;

JDevlieghere wrote:
> jasonliu wrote:
> > apaprocki wrote:
> > > No need to be `sorry:` :) This should probably just say `error: XCOFF is 
> > > unimplemented` to be more direct in case anything is expecting "error:" 
> > > in the output.
> > Sure. Will address in next revision.
> Just bundle this with the WASM case, the error message is correct for both.
I think they are different. 
The error message for WASM seems to suggest that it will never ever get 
supported on WASM. 
But it is not the case for XCOFF, we want to indicate that it is not 
implemented yet.  


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58930/new/

https://reviews.llvm.org/D58930



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

[Lldb-commits] [PATCH] D58972: Introduce the "Formats" module and move LinuxProcMaps parser to it

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere added a comment.

In D58972#1418931 , @labath wrote:

> FileFormats wouldn't be generic enough to capture the gdb-remote or 
> debug-info-server protocol code. However, even calling gdb-remote protocol a 
> "format" is still a bit of a stretch. I think there is enough similarity 
> between gdb-remote and minidump code for them to be in the same module (both 
> convert some (and often the same) data structures into some (file or wire) 
> format), but they're also sufficiently different for them to live in 
> different places. So yeah, if we want the protocol code to live in a 
> different library (Protocols ?), then FileFormats is a better name here.


I was going to propose `Protocols` for consideration but that doesn't really 
work for minidump. Thinking a little about this, `Formats`, although generic, 
is probably the best.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58972/new/

https://reviews.llvm.org/D58972



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

[Lldb-commits] [PATCH] D58930: Add XCOFF triple object format type for AIX

[Jason Liu via Phabricator via lldb-commits]

jasonliu marked 3 inline comments as done.
jasonliu added inline comments.



Comment at: clang/lib/CodeGen/BackendUtil.cpp:1470
+  case Triple::XCOFF:
+// TODO: Falling through for XCOFF format for now.
+break;

JDevlieghere wrote:
> This is confusing, you say fall through but you break? I would prefer a 
> `llvm_unreachable("XCOFF not yet implemented");` here and elsewhere in this 
> patch. 
> 
Thanks for the comment. Will address in next revision. 



Comment at: clang/lib/CodeGen/BackendUtil.cpp:1486
+  case Triple::XCOFF:
+// TODO: Falling through for XCOFF format for now.
+break;

JDevlieghere wrote:
> See previous comment.
Will address in next revision.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:4410
+  case llvm::Triple::XCOFF:
+llvm_unreachable("to be determined for XCOFF format");
   case llvm::Triple::COFF:

JDevlieghere wrote:
> See previous comment.
Will address in next revision.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58930/new/

https://reviews.llvm.org/D58930



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

[Lldb-commits] [lldb] r355443 - [lldbsuite, windows] Skip the TestEvents tests on Windows

[Stella Stamenova via lldb-commits]

Author: stella.stamenova
Date: Tue Mar  5 13:03:36 2019
New Revision: 355443

URL: http://llvm.org/viewvc/llvm-project?rev=355443&view=rev
Log:
[lldbsuite, windows] Skip the TestEvents tests on Windows

These tests are flakey on Windows and recently they have started failing AND 
also hanging the whole suite when they fail.

Modified:
lldb/trunk/packages/Python/lldbsuite/test/python_api/event/TestEvents.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/python_api/event/TestEvents.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/python_api/event/TestEvents.py?rev=355443&r1=355442&r2=355443&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/python_api/event/TestEvents.py 
(original)
+++ lldb/trunk/packages/Python/lldbsuite/test/python_api/event/TestEvents.py 
Tue Mar  5 13:03:36 2019
@@ -31,6 +31,7 @@ class EventAPITestCase(TestBase):
 @expectedFailureAll(
 oslist=["linux"],
 bugnumber="llvm.org/pr23730 Flaky, fails ~1/10 cases")
+@skipIfWindows # This is flakey on Windows AND when it fails, it hangs: 
llvm.org/pr38373
 def test_listen_for_and_print_event(self):
 """Exercise SBEvent API."""
 self.build()
@@ -119,6 +120,7 @@ class EventAPITestCase(TestBase):
 
 @add_test_categories(['pyapi'])
 @expectedFlakeyLinux("llvm.org/pr23730")  # Flaky, fails ~1/100 cases
+@skipIfWindows # This is flakey on Windows AND when it fails, it hangs: 
llvm.org/pr38373
 def test_wait_for_event(self):
 """Exercise SBListener.WaitForEvent() API."""
 self.build()
@@ -197,6 +199,7 @@ class EventAPITestCase(TestBase):
 @expectedFailureAll(
 oslist=["linux"],
 bugnumber="llvm.org/pr23617 Flaky, fails ~1/10 cases")
+@skipIfWindows # This is flakey on Windows AND when it fails, it hangs: 
llvm.org/pr38373
 def test_add_listener_to_broadcaster(self):
 """Exercise some SBBroadcaster APIs."""
 self.build()


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

[Lldb-commits] [PATCH] D58748: [ExpressionParser] Test GetClangResourceDir

[Alex Langford via Phabricator via lldb-commits]

xiaobai updated this revision to Diff 189392.
xiaobai added a comment.

{Default,}ComputeClangDirectory -> {Default,}ComputeClangResourceDir
Added a comment explaining exactly how DefaultComputeClangResourceDir works


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58748/new/

https://reviews.llvm.org/D58748

Files:
  packages/Python/lldbsuite/test/functionalities/paths/TestPaths.py
  source/Plugins/ExpressionParser/Clang/ClangHost.cpp
  source/Plugins/ExpressionParser/Clang/ClangHost.h
  unittests/Expression/ClangParserTest.cpp

Index: unittests/Expression/ClangParserTest.cpp
===
--- unittests/Expression/ClangParserTest.cpp
+++ unittests/Expression/ClangParserTest.cpp
@@ -6,6 +6,8 @@
 //
 //===--===//
 
+#include "clang/Basic/Version.h"
+
 #include "Plugins/ExpressionParser/Clang/ClangHost.h"
 #include "TestingSupport/TestUtilities.h"
 #include "lldb/Host/FileSystem.h"
@@ -29,32 +31,44 @@
 };
 } // namespace
 
-#ifdef __APPLE__
-static std::string ComputeClangDir(std::string lldb_shlib_path,
-   bool verify = false) {
+#if !defined(_WIN32)
+static std::string ComputeClangResourceDir(std::string lldb_shlib_path,
+   bool verify = false) {
   FileSpec clang_dir;
   FileSpec lldb_shlib_spec(lldb_shlib_path);
-  ComputeClangDirectory(lldb_shlib_spec, clang_dir, verify);
+  ComputeClangResourceDirectory(lldb_shlib_spec, clang_dir, verify);
   return clang_dir.GetPath();
 }
 
+TEST_F(ClangHostTest, ComputeClangResourceDirectory) {
+  std::string path_to_liblldb = "/foo/bar/lib/";
+  std::string path_to_clang_dir = "/foo/bar/lib/clang/" CLANG_VERSION_STRING;
+  EXPECT_EQ(ComputeClangResourceDir(path_to_liblldb), path_to_clang_dir);
+
+  // The path doesn't really exist, so setting verify to true should make
+  // ComputeClangResourceDir to not give you path_to_clang_dir.
+  EXPECT_NE(ComputeClangResourceDir(path_to_liblldb, true),
+ComputeClangResourceDir(path_to_liblldb));
+}
+
+#if defined(__APPLE__)
 TEST_F(ClangHostTest, MacOSX) {
   // This returns whatever the POSIX fallback returns.
   std::string posix = "/usr/lib/liblldb.dylib";
-  EXPECT_FALSE(ComputeClangDir(posix).empty());
+  EXPECT_FALSE(ComputeClangResourceDir(posix).empty());
 
   std::string build =
   "/lldb-macosx-x86_64/Library/Frameworks/LLDB.framework/Versions/A";
   std::string build_clang =
   "/lldb-macosx-x86_64/Library/Frameworks/LLDB.framework/Resources/Clang";
-  EXPECT_EQ(ComputeClangDir(build), build_clang);
+  EXPECT_EQ(ComputeClangResourceDir(build), build_clang);
 
   std::string xcode = "/Applications/Xcode.app/Contents/SharedFrameworks/"
   "LLDB.framework/Versions/A";
   std::string xcode_clang =
   "/Applications/Xcode.app/Contents/Developer/Toolchains/"
   "XcodeDefault.xctoolchain/usr/lib/swift/clang";
-  EXPECT_EQ(ComputeClangDir(xcode), xcode_clang);
+  EXPECT_EQ(ComputeClangResourceDir(xcode), xcode_clang);
 
   std::string toolchain =
   "/Applications/Xcode.app/Contents/Developer/Toolchains/"
@@ -63,17 +77,18 @@
   std::string toolchain_clang =
   "/Applications/Xcode.app/Contents/Developer/Toolchains/"
   "Swift-4.1-development-snapshot.xctoolchain/usr/lib/swift/clang";
-  EXPECT_EQ(ComputeClangDir(toolchain), toolchain_clang);
+  EXPECT_EQ(ComputeClangResourceDir(toolchain), toolchain_clang);
 
   std::string cltools = "/Library/Developer/CommandLineTools/Library/"
 "PrivateFrameworks/LLDB.framework";
   std::string cltools_clang =
   "/Library/Developer/CommandLineTools/Library/PrivateFrameworks/"
   "LLDB.framework/Resources/Clang";
-  EXPECT_EQ(ComputeClangDir(cltools), cltools_clang);
+  EXPECT_EQ(ComputeClangResourceDir(cltools), cltools_clang);
 
   // Test that a bogus path is detected.
-  EXPECT_NE(ComputeClangDir(GetInputFilePath(xcode), true),
-ComputeClangDir(GetInputFilePath(xcode)));
+  EXPECT_NE(ComputeClangResourceDir(GetInputFilePath(xcode), true),
+ComputeClangResourceDir(GetInputFilePath(xcode)));
 }
-#endif
+#endif // __APPLE__
+#endif // !_WIN32
Index: source/Plugins/ExpressionParser/Clang/ClangHost.h
===
--- source/Plugins/ExpressionParser/Clang/ClangHost.h
+++ source/Plugins/ExpressionParser/Clang/ClangHost.h
@@ -13,9 +13,9 @@
 
 class FileSpec;
 
-#if defined(__APPLE__)
-bool ComputeClangDirectory(FileSpec &lldb_shlib_spec, FileSpec &file_spec,
-   bool verify);
+#if !defined(_WIN32)
+bool ComputeClangResourceDirectory(FileSpec &lldb_shlib_spec,
+   FileSpec &file_spec, bool verify);
 #endif
 
 FileSpec GetClangResourceDir();
Index: source/Plugins/ExpressionParser/Clang/ClangHost.cpp
===
--- 

[Lldb-commits] [lldb] r355448 - [lit, windows] Disable stop-hook-threads on Windows

[Stella Stamenova via lldb-commits]

Author: stella.stamenova
Date: Tue Mar  5 13:43:04 2019
New Revision: 355448

URL: http://llvm.org/viewvc/llvm-project?rev=355448&view=rev
Log:
[lit, windows] Disable stop-hook-threads on Windows

This test is also no longer reliably failing or passing on Windows and it is 
hanging every few runs.

Modified:
lldb/trunk/lit/ExecControl/StopHook/stop-hook-threads.test

Modified: lldb/trunk/lit/ExecControl/StopHook/stop-hook-threads.test
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/ExecControl/StopHook/stop-hook-threads.test?rev=355448&r1=355447&r2=355448&view=diff
==
--- lldb/trunk/lit/ExecControl/StopHook/stop-hook-threads.test (original)
+++ lldb/trunk/lit/ExecControl/StopHook/stop-hook-threads.test Tue Mar  5 
13:43:04 2019
@@ -4,7 +4,8 @@
 # RUN: %lldb -b -s %p/Inputs/stop-hook-threads-2.lldbinit -s %s -f %t \
 # RUN: | FileCheck --check-prefix=CHECK --check-prefix=CHECK-FILTER %s
 # XFAIL: system-netbsd
-# XFAIL: system-windows
+# UNSUPPORTED: system-windows
+# This test is flakey and hangs on windows periodically: llvm.org/pr38373
 # UNSUPPORTED: system-linux
 
 thread list


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

[Lldb-commits] [lldb] r355449 - Revert logging addition to SBCompileUnit::GetNumLineEntries,

[Jason Molenda via lldb-commits]

Author: jmolenda
Date: Tue Mar  5 14:17:47 2019
New Revision: 355449

URL: http://llvm.org/viewvc/llvm-project?rev=355449&view=rev
Log:
Revert logging addition to SBCompileUnit::GetNumLineEntries,
causing lldb-mi testsuite failures?  

Modified:
lldb/trunk/source/API/SBCompileUnit.cpp

Modified: lldb/trunk/source/API/SBCompileUnit.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/API/SBCompileUnit.cpp?rev=355449&r1=355448&r2=355449&view=diff
==
--- lldb/trunk/source/API/SBCompileUnit.cpp (original)
+++ lldb/trunk/source/API/SBCompileUnit.cpp Tue Mar  5 14:17:47 2019
@@ -43,15 +43,10 @@ SBFileSpec SBCompileUnit::GetFileSpec()
 }
 
 uint32_t SBCompileUnit::GetNumLineEntries() const {
-  Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_API));
   if (m_opaque_ptr) {
 LineTable *line_table = m_opaque_ptr->GetLineTable();
-if (line_table) {
-  log->Printf("SBCompileUnit(%p)::GetNumLineEntries() => %d",
-static_cast(m_opaque_ptr), 
-(int)line_table->GetSize());
+if (line_table)
   return line_table->GetSize();
-}
   }
   return 0;
 }


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

Re: [Lldb-commits] [lldb] r355449 - Revert logging addition to SBCompileUnit::GetNumLineEntries,

[Davide Italiano via lldb-commits]

You should check whether log is enabled, I think.

On Tue, Mar 5, 2019 at 2:16 PM Jason Molenda via lldb-commits
 wrote:
>
> Author: jmolenda
> Date: Tue Mar  5 14:17:47 2019
> New Revision: 355449
>
> URL: http://llvm.org/viewvc/llvm-project?rev=355449&view=rev
> Log:
> Revert logging addition to SBCompileUnit::GetNumLineEntries,
> causing lldb-mi testsuite failures?
>
> Modified:
> lldb/trunk/source/API/SBCompileUnit.cpp
>
> Modified: lldb/trunk/source/API/SBCompileUnit.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/API/SBCompileUnit.cpp?rev=355449&r1=355448&r2=355449&view=diff
> ==
> --- lldb/trunk/source/API/SBCompileUnit.cpp (original)
> +++ lldb/trunk/source/API/SBCompileUnit.cpp Tue Mar  5 14:17:47 2019
> @@ -43,15 +43,10 @@ SBFileSpec SBCompileUnit::GetFileSpec()
>  }
>
>  uint32_t SBCompileUnit::GetNumLineEntries() const {
> -  Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_API));
>if (m_opaque_ptr) {
>  LineTable *line_table = m_opaque_ptr->GetLineTable();
> -if (line_table) {
> -  log->Printf("SBCompileUnit(%p)::GetNumLineEntries() => %d",
> -static_cast(m_opaque_ptr),
> -(int)line_table->GetSize());
> +if (line_table)
>return line_table->GetSize();
> -}
>}
>return 0;
>  }
>
>
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r355449 - Revert logging addition to SBCompileUnit::GetNumLineEntries,

[Jason Molenda via lldb-commits]

Yeah, I realized that as I re-read the diff after reverting. :)   I was doing 
all my work & testing with the api log enabled.


> On Mar 5, 2019, at 2:21 PM, Davide Italiano  wrote:
> 
> You should check whether log is enabled, I think.
> 
> On Tue, Mar 5, 2019 at 2:16 PM Jason Molenda via lldb-commits
>  wrote:
>> 
>> Author: jmolenda
>> Date: Tue Mar  5 14:17:47 2019
>> New Revision: 355449
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=355449&view=rev
>> Log:
>> Revert logging addition to SBCompileUnit::GetNumLineEntries,
>> causing lldb-mi testsuite failures?
>> 
>> Modified:
>>lldb/trunk/source/API/SBCompileUnit.cpp
>> 
>> Modified: lldb/trunk/source/API/SBCompileUnit.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/API/SBCompileUnit.cpp?rev=355449&r1=355448&r2=355449&view=diff
>> ==
>> --- lldb/trunk/source/API/SBCompileUnit.cpp (original)
>> +++ lldb/trunk/source/API/SBCompileUnit.cpp Tue Mar  5 14:17:47 2019
>> @@ -43,15 +43,10 @@ SBFileSpec SBCompileUnit::GetFileSpec()
>> }
>> 
>> uint32_t SBCompileUnit::GetNumLineEntries() const {
>> -  Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_API));
>>   if (m_opaque_ptr) {
>> LineTable *line_table = m_opaque_ptr->GetLineTable();
>> -if (line_table) {
>> -  log->Printf("SBCompileUnit(%p)::GetNumLineEntries() => %d",
>> -static_cast(m_opaque_ptr),
>> -(int)line_table->GetSize());
>> +if (line_table)
>>   return line_table->GetSize();
>> -}
>>   }
>>   return 0;
>> }
>> 
>> 
>> ___
>> lldb-commits mailing list
>> lldb-commits@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

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

Re: [Lldb-commits] [lldb] r355406 - Revert "Fix embedded Python initialization according to changes in version 3.7"

[Stella Stamenova via lldb-commits]

It should be safe to checkin the change now. It looks like at some point during 
the last couple of days the timing of some of the threads tests on Windows 
changed so now instead of behaving and passing or failing nicely, they are 
getting struck and never completing. This does not happen on every run and the 
python change just happened to coincide with some of the failures.

I've disabled the two tests that seemed to be the cause of the issue, so that 
the bot can go back to green.

Thanks
-Stella

-Original Message-
From: Stella Stamenova 
Sent: Tuesday, March 5, 2019 10:26 AM
To: 'Davide Italiano' 
Cc: Tatyana Krasnukha ; lldb-commits 

Subject: RE: [Lldb-commits] [lldb] r355406 - Revert "Fix embedded Python 
initialization according to changes in version 3.7"

I ran the tests without that line on a machine that is equivalent to the 
Buildbot and they ran correctly, but I just noticed that while the Buildbot has 
had several runs that did not time out since the revert, there was also one 
that did time out.

I am going to let the current build on the Buildbot complete (since it should 
be green as a fix was committed for the other failure) and I'm going to restart 
it afterwards.

In the mean time, I am running the tests on the machine that is the same with 
the full python 3.7 change to confirm whether it hangs there too or if it was 
somehow bot specific.

Thanks,
-Stella

-Original Message-
From: Davide Italiano 
Sent: Tuesday, March 5, 2019 8:43 AM
To: Stella Stamenova 
Cc: Tatyana Krasnukha ; lldb-commits 

Subject: Re: [Lldb-commits] [lldb] r355406 - Revert "Fix embedded Python 
initialization according to changes in version 3.7"

On Tue, Mar 5, 2019 at 8:39 AM Stella Stamenova  wrote:
>
> The bot is running 3.6.6 and it does not have python 3.7 installed (it does 
> have python 2.7 which is needed to run Buildbot).
>
> The change that was pushed, though, did not only impact python 3.7:
>
> m_was_already_initialized == PyGILState_UNLOCKED ? "un" : "");
> m_gil_state == PyGILState_UNLOCKED ? "un" : "");
>
> It replaced m_was_already_initialized above with m_gil_state - for *any* 
> version of python. Yes, this is just in a log, but my guess is that that's 
> the source of the hang on Windows not the 3.7 specific code.
>
> If you end up with a  prototype change that you want to commit, I can run a 
> local test to see whether the tests pass with it.
>

Can you just revert that chunk of unconditional python code and try?
(it's extremely surprising to me that the change caused the bots to hang, even 
if it's unconditional, anyway).

i.e.

+// Since Python 3.7 `Py_Initialize` calls `PyEval_InitThreads` inside 
+itself, // so there is no way to determine whether the embedded 
+interpreter // was already initialized by some external code.
+`PyEval_ThreadsInitialized` // would always return `true` and 
+`PyGILState_Ensure/Release` flow would be // executed instead of 
+unlocking GIL with `PyEval_SaveThread`. When // an another thread calls 
`PyGILState_Ensure` it would get stuck in deadlock.
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 7) || 
+(PY_MAJOR_VERSION > 3) // The only case we should go further and acquire the 
GIL: it is unlocked.
+if (PyGILState_Check())
+  return;
+#endif
+

and let us know if the bot still hangs?

Thanks,

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

[Lldb-commits] [PATCH] D58930: Add XCOFF triple object format type for AIX

[Jason Liu via Phabricator via lldb-commits]

jasonliu marked an inline comment as done.
jasonliu added inline comments.



Comment at: llvm/lib/MC/MCContext.cpp:165
+case MCObjectFileInfo::IsXCOFF:
+  // TODO: Need to implement class MCSymbolXCOFF.
+  break;

JDevlieghere wrote:
> See previous comment.
It is certain that we will need MCSymbolXCOFF. But before we run into cases 
where we actually need a MCSymbolXCOFF, we could use the generic MCSymbol first 
for XCOFF platform. So I don't want to put a llvm_unreachable here. 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58930/new/

https://reviews.llvm.org/D58930



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

[Lldb-commits] [PATCH] D58930: Add XCOFF triple object format type for AIX

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere added inline comments.



Comment at: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp:2079
+  if (log)
+log->Printf("sorry: unimplemented for XCOFF");
+  return false;

jasonliu wrote:
> JDevlieghere wrote:
> > jasonliu wrote:
> > > apaprocki wrote:
> > > > No need to be `sorry:` :) This should probably just say `error: XCOFF 
> > > > is unimplemented` to be more direct in case anything is expecting 
> > > > "error:" in the output.
> > > Sure. Will address in next revision.
> > Just bundle this with the WASM case, the error message is correct for both.
> I think they are different. 
> The error message for WASM seems to suggest that it will never ever get 
> supported on WASM. 
> But it is not the case for XCOFF, we want to indicate that it is not 
> implemented yet.  
I don't think the error message suggests that at all, and it's definitely not 
true. At this point neither XCOFF nor WASM is supported, and that's exactly 
what the log message says.



Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58930/new/

https://reviews.llvm.org/D58930



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

[Lldb-commits] [PATCH] D59004: [lldb] Fix DW_OP_addrx uses.

[Ali Tamur via Phabricator via lldb-commits]

tamur created this revision.
tamur added a project: LLDB.
Herald added a subscriber: lldb-commits.

DW_OP_GNU_addr_index has been renamed as DW_OP_addrx in the standard. clang 
produces DW_OP_addrx tags and with this change lldb starts to process them.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D59004

Files:
  lldb/source/Expression/DWARFExpression.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp
  lldb/source/Plugins/SymbolFile/DWARF/HashedNameToDIE.cpp

Index: lldb/source/Plugins/SymbolFile/DWARF/HashedNameToDIE.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/HashedNameToDIE.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/HashedNameToDIE.cpp
@@ -166,6 +166,7 @@
   case DW_FORM_ref_sig8:
 llvm_unreachable("Unhandled atom form");
 
+  case DW_FORM_addrx:
   case DW_FORM_string:
   case DW_FORM_block:
   case DW_FORM_block1:
Index: lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp
@@ -681,6 +681,7 @@
 return 1;
   switch (a_form) {
   case DW_FORM_addr:
+  case DW_FORM_addrx:
   case DW_FORM_flag:
   case DW_FORM_data1:
   case DW_FORM_data2:
Index: lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
@@ -326,6 +326,7 @@
 break;
 
   // signed or unsigned LEB 128 values
+  case DW_FORM_addrx:
   case DW_FORM_sdata:
   case DW_FORM_udata:
   case DW_FORM_ref_udata:
@@ -456,6 +457,7 @@
 
 case DW_AT_high_pc:
   if (form_value.Form() == DW_FORM_addr ||
+  form_value.Form() == DW_FORM_addrx ||
   form_value.Form() == DW_FORM_GNU_addr_index) {
 hi_pc = form_value.Address();
   } else {
@@ -1031,7 +1033,8 @@
   if (GetAttributeValue(dwarf2Data, cu, DW_AT_high_pc, form_value, nullptr,
 check_specification_or_abstract_origin)) {
 dw_form_t form = form_value.Form();
-if (form == DW_FORM_addr || form == DW_FORM_GNU_addr_index)
+if (form == DW_FORM_addr || form == DW_FORM_addrx ||
+form == DW_FORM_GNU_addr_index)
   return form_value.Address();
 
 // DWARF4 can specify the hi_pc as an 
Index: lldb/source/Expression/DWARFExpression.cpp
===
--- lldb/source/Expression/DWARFExpression.cpp
+++ lldb/source/Expression/DWARFExpression.cpp
@@ -514,6 +514,10 @@
   s->Printf("DW_OP_GNU_addr_index(0x%" PRIx64 ")",
 m_data.GetULEB128(&offset));
   break;
+case DW_OP_addrx:
+  s->Printf("DW_OP_addrx(0x%" PRIx64 ")",
+m_data.GetULEB128(&offset));
+  break;
 case DW_OP_GNU_const_index: // 0xfc
   s->Printf("DW_OP_GNU_const_index(0x%" PRIx64 ")",
 m_data.GetULEB128(&offset));
@@ -877,6 +881,7 @@
 return 8;
 
   // All opcodes that have a single ULEB (signed or unsigned) argument
+  case DW_OP_addrx:   // 0xa1 1 ULEB128 index
   case DW_OP_constu:  // 0x10 1 ULEB128 constant
   case DW_OP_consts:  // 0x11 1 SLEB128 constant
   case DW_OP_plus_uconst: // 0x23 1 ULEB128 addend
@@ -957,7 +962,7 @@
 return op_file_addr;
   else
 ++curr_op_addr_idx;
-} else if (op == DW_OP_GNU_addr_index) {
+} else if (op == DW_OP_GNU_addr_index || op == DW_OP_addrx) {
   uint64_t index = m_data.GetULEB128(&offset);
   if (curr_op_addr_idx == op_addr_idx) {
 if (!m_dwarf_cu) {
@@ -2909,6 +2914,7 @@
 // section with the base address specified by the DW_AT_addr_base attribute
 // and the 0 based index is the ULEB128 encoded index.
 //--
+case DW_OP_addrx:
 case DW_OP_GNU_addr_index: {
   if (!dwarf_cu) {
 if (error_ptr)
@@ -3194,6 +3200,7 @@
   case DW_OP_call_ref:
 size = dwarf_ref_size;
 break;
+  case DW_OP_addrx:
   case DW_OP_piece:
   case DW_OP_plus_uconst:
   case DW_OP_regx:
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D59004: [lldb] Fix DW_OP_addrx uses.

[Shafik Yaghmour via Phabricator via lldb-commits]

shafik added inline comments.



Comment at: lldb/source/Expression/DWARFExpression.cpp:2910
 //--
 // OPCODE: DW_OP_GNU_addr_index
 // OPERANDS: 1

Should this comment be updated?


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59004/new/

https://reviews.llvm.org/D59004



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

[Lldb-commits] [lldb] r355457 - Remove tautological #ifdefs (NFC)

[Adrian Prantl via lldb-commits]

Author: adrian
Date: Tue Mar  5 15:51:25 2019
New Revision: 355457

URL: http://llvm.org/viewvc/llvm-project?rev=355457&view=rev
Log:
Remove tautological #ifdefs (NFC)

Differential Revision: https://reviews.llvm.org/D58838

Modified:
lldb/trunk/source/Target/ExecutionContext.cpp

Modified: lldb/trunk/source/Target/ExecutionContext.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/ExecutionContext.cpp?rev=355457&r1=355456&r2=355457&view=diff
==
--- lldb/trunk/source/Target/ExecutionContext.cpp (original)
+++ lldb/trunk/source/Target/ExecutionContext.cpp Tue Mar  5 15:51:25 2019
@@ -224,30 +224,22 @@ ExecutionContextScope *ExecutionContext:
 }
 
 Target &ExecutionContext::GetTargetRef() const {
-#if defined(LLDB_CONFIGURATION_DEBUG) || defined(LLDB_CONFIGURATION_RELEASE)
   assert(m_target_sp);
-#endif
   return *m_target_sp;
 }
 
 Process &ExecutionContext::GetProcessRef() const {
-#if defined(LLDB_CONFIGURATION_DEBUG) || defined(LLDB_CONFIGURATION_RELEASE)
   assert(m_process_sp);
-#endif
   return *m_process_sp;
 }
 
 Thread &ExecutionContext::GetThreadRef() const {
-#if defined(LLDB_CONFIGURATION_DEBUG) || defined(LLDB_CONFIGURATION_RELEASE)
   assert(m_thread_sp);
-#endif
   return *m_thread_sp;
 }
 
 StackFrame &ExecutionContext::GetFrameRef() const {
-#if defined(LLDB_CONFIGURATION_DEBUG) || defined(LLDB_CONFIGURATION_RELEASE)
   assert(m_frame_sp);
-#endif
   return *m_frame_sp;
 }
 


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

[Lldb-commits] [PATCH] D58838: Remove tautological #ifdefs

[Phabricator via Phabricator via lldb-commits]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rL355457: Remove tautological #ifdefs (NFC) (authored by 
adrian, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D58838?vs=189003&id=189413#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58838/new/

https://reviews.llvm.org/D58838

Files:
  lldb/trunk/source/Target/ExecutionContext.cpp


Index: lldb/trunk/source/Target/ExecutionContext.cpp
===
--- lldb/trunk/source/Target/ExecutionContext.cpp
+++ lldb/trunk/source/Target/ExecutionContext.cpp
@@ -224,30 +224,22 @@
 }
 
 Target &ExecutionContext::GetTargetRef() const {
-#if defined(LLDB_CONFIGURATION_DEBUG) || defined(LLDB_CONFIGURATION_RELEASE)
   assert(m_target_sp);
-#endif
   return *m_target_sp;
 }
 
 Process &ExecutionContext::GetProcessRef() const {
-#if defined(LLDB_CONFIGURATION_DEBUG) || defined(LLDB_CONFIGURATION_RELEASE)
   assert(m_process_sp);
-#endif
   return *m_process_sp;
 }
 
 Thread &ExecutionContext::GetThreadRef() const {
-#if defined(LLDB_CONFIGURATION_DEBUG) || defined(LLDB_CONFIGURATION_RELEASE)
   assert(m_thread_sp);
-#endif
   return *m_thread_sp;
 }
 
 StackFrame &ExecutionContext::GetFrameRef() const {
-#if defined(LLDB_CONFIGURATION_DEBUG) || defined(LLDB_CONFIGURATION_RELEASE)
   assert(m_frame_sp);
-#endif
   return *m_frame_sp;
 }
 


Index: lldb/trunk/source/Target/ExecutionContext.cpp
===
--- lldb/trunk/source/Target/ExecutionContext.cpp
+++ lldb/trunk/source/Target/ExecutionContext.cpp
@@ -224,30 +224,22 @@
 }
 
 Target &ExecutionContext::GetTargetRef() const {
-#if defined(LLDB_CONFIGURATION_DEBUG) || defined(LLDB_CONFIGURATION_RELEASE)
   assert(m_target_sp);
-#endif
   return *m_target_sp;
 }
 
 Process &ExecutionContext::GetProcessRef() const {
-#if defined(LLDB_CONFIGURATION_DEBUG) || defined(LLDB_CONFIGURATION_RELEASE)
   assert(m_process_sp);
-#endif
   return *m_process_sp;
 }
 
 Thread &ExecutionContext::GetThreadRef() const {
-#if defined(LLDB_CONFIGURATION_DEBUG) || defined(LLDB_CONFIGURATION_RELEASE)
   assert(m_thread_sp);
-#endif
   return *m_thread_sp;
 }
 
 StackFrame &ExecutionContext::GetFrameRef() const {
-#if defined(LLDB_CONFIGURATION_DEBUG) || defined(LLDB_CONFIGURATION_RELEASE)
   assert(m_frame_sp);
-#endif
   return *m_frame_sp;
 }
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D59004: [lldb] Fix DW_OP_addrx uses.

[Ali Tamur via Phabricator via lldb-commits]

tamur updated this revision to Diff 189415.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59004/new/

https://reviews.llvm.org/D59004

Files:
  lldb/source/Expression/DWARFExpression.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp
  lldb/source/Plugins/SymbolFile/DWARF/HashedNameToDIE.cpp

Index: lldb/source/Plugins/SymbolFile/DWARF/HashedNameToDIE.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/HashedNameToDIE.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/HashedNameToDIE.cpp
@@ -166,6 +166,7 @@
   case DW_FORM_ref_sig8:
 llvm_unreachable("Unhandled atom form");
 
+  case DW_FORM_addrx:
   case DW_FORM_string:
   case DW_FORM_block:
   case DW_FORM_block1:
Index: lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp
@@ -681,6 +681,7 @@
 return 1;
   switch (a_form) {
   case DW_FORM_addr:
+  case DW_FORM_addrx:
   case DW_FORM_flag:
   case DW_FORM_data1:
   case DW_FORM_data2:
Index: lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
@@ -326,6 +326,7 @@
 break;
 
   // signed or unsigned LEB 128 values
+  case DW_FORM_addrx:
   case DW_FORM_sdata:
   case DW_FORM_udata:
   case DW_FORM_ref_udata:
@@ -456,6 +457,7 @@
 
 case DW_AT_high_pc:
   if (form_value.Form() == DW_FORM_addr ||
+  form_value.Form() == DW_FORM_addrx ||
   form_value.Form() == DW_FORM_GNU_addr_index) {
 hi_pc = form_value.Address();
   } else {
@@ -1031,7 +1033,8 @@
   if (GetAttributeValue(dwarf2Data, cu, DW_AT_high_pc, form_value, nullptr,
 check_specification_or_abstract_origin)) {
 dw_form_t form = form_value.Form();
-if (form == DW_FORM_addr || form == DW_FORM_GNU_addr_index)
+if (form == DW_FORM_addr || form == DW_FORM_addrx ||
+form == DW_FORM_GNU_addr_index)
   return form_value.Address();
 
 // DWARF4 can specify the hi_pc as an 
Index: lldb/source/Expression/DWARFExpression.cpp
===
--- lldb/source/Expression/DWARFExpression.cpp
+++ lldb/source/Expression/DWARFExpression.cpp
@@ -514,6 +514,10 @@
   s->Printf("DW_OP_GNU_addr_index(0x%" PRIx64 ")",
 m_data.GetULEB128(&offset));
   break;
+case DW_OP_addrx:
+  s->Printf("DW_OP_addrx(0x%" PRIx64 ")",
+m_data.GetULEB128(&offset));
+  break;
 case DW_OP_GNU_const_index: // 0xfc
   s->Printf("DW_OP_GNU_const_index(0x%" PRIx64 ")",
 m_data.GetULEB128(&offset));
@@ -877,6 +881,7 @@
 return 8;
 
   // All opcodes that have a single ULEB (signed or unsigned) argument
+  case DW_OP_addrx:   // 0xa1 1 ULEB128 index
   case DW_OP_constu:  // 0x10 1 ULEB128 constant
   case DW_OP_consts:  // 0x11 1 SLEB128 constant
   case DW_OP_plus_uconst: // 0x23 1 ULEB128 addend
@@ -957,7 +962,7 @@
 return op_file_addr;
   else
 ++curr_op_addr_idx;
-} else if (op == DW_OP_GNU_addr_index) {
+} else if (op == DW_OP_GNU_addr_index || op == DW_OP_addrx) {
   uint64_t index = m_data.GetULEB128(&offset);
   if (curr_op_addr_idx == op_addr_idx) {
 if (!m_dwarf_cu) {
@@ -2902,13 +2907,14 @@
 } break;
 
 //--
-// OPCODE: DW_OP_GNU_addr_index
+// OPCODE: DW_OP_addrx (DW_OP_GNU_addr_index is the legacy name.)
 // OPERANDS: 1
 //  ULEB128: index to the .debug_addr section
 // DESCRIPTION: Pushes an address to the stack from the .debug_addr
 // section with the base address specified by the DW_AT_addr_base attribute
 // and the 0 based index is the ULEB128 encoded index.
 //--
+case DW_OP_addrx:
 case DW_OP_GNU_addr_index: {
   if (!dwarf_cu) {
 if (error_ptr)
@@ -3194,6 +3200,7 @@
   case DW_OP_call_ref:
 size = dwarf_ref_size;
 break;
+  case DW_OP_addrx:
   case DW_OP_piece:
   case DW_OP_plus_uconst:
   case DW_OP_regx:
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D59004: [lldb] Fix DW_OP_addrx uses.

[Ali Tamur via Phabricator via lldb-commits]

tamur marked an inline comment as done.
tamur added inline comments.



Comment at: lldb/source/Expression/DWARFExpression.cpp:2910
 //--
 // OPCODE: DW_OP_GNU_addr_index
 // OPERANDS: 1

shafik wrote:
> Should this comment be updated?
Updated the comment.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59004/new/

https://reviews.llvm.org/D59004



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

[Lldb-commits] [PATCH] D59004: [lldb] Fix DW_OP_addrx uses.

[Adrian Prantl via Phabricator via lldb-commits]

aprantl added a comment.

The code looks fine, but this needs a testcase.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59004/new/

https://reviews.llvm.org/D59004



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

[Lldb-commits] [PATCH] D59004: [lldb] Fix DW_OP_addrx uses.

[Adrian Prantl via Phabricator via lldb-commits]

aprantl added a comment.

Is there a way to force clang to generate this and/or are existing tests 
failing because this support is missing?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59004/new/

https://reviews.llvm.org/D59004



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

[Lldb-commits] [lldb] r355458 - [SBAPI] Don't check IsValid in constructor

[Jonas Devlieghere via lldb-commits]

Author: jdevlieghere
Date: Tue Mar  5 16:05:55 2019
New Revision: 355458

URL: http://llvm.org/viewvc/llvm-project?rev=355458&view=rev
Log:
[SBAPI] Don't check IsValid in constructor

When running the test suite with the instrumentation macros, I noticed
two lldb-mi tests regressed. The issue was the copy constructor of
SBLineEntry. Without the macros the returned value would be elided, but
with the macros the copy constructor was called. The latter using ::IsValid
to determine whether the underlying opaque pointer should be set. This
is likely a remnant of when ::IsValid would only check the validity of the
smart pointer. In SBLineEntry however, it actually forwards to
LineEntry::IsValid().

So what happened here was that because of the macros the copy
constructor was called. The opaque pointer was valid but the LineEntry
didn't consider itself valid. So the copied-to object ended up default
initialized.

This patch replaces all checks for IsValid in copy (assignment)
constructors with checks for the opaque pointer itself.

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

Added:
lldb/trunk/source/API/Utils.h
Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
lldb/trunk/source/API/SBAddress.cpp
lldb/trunk/source/API/SBAttachInfo.cpp
lldb/trunk/source/API/SBCommandReturnObject.cpp
lldb/trunk/source/API/SBDeclaration.cpp
lldb/trunk/source/API/SBError.cpp
lldb/trunk/source/API/SBExpressionOptions.cpp
lldb/trunk/source/API/SBFileSpec.cpp
lldb/trunk/source/API/SBFileSpecList.cpp
lldb/trunk/source/API/SBFrame.cpp
lldb/trunk/source/API/SBLineEntry.cpp
lldb/trunk/source/API/SBMemoryRegionInfo.cpp
lldb/trunk/source/API/SBModuleSpec.cpp
lldb/trunk/source/API/SBProcessInfo.cpp
lldb/trunk/source/API/SBStringList.cpp
lldb/trunk/source/API/SBSymbolContext.cpp
lldb/trunk/source/API/SBSymbolContextList.cpp
lldb/trunk/source/API/SBThread.cpp
lldb/trunk/source/API/SBTypeEnumMember.cpp
lldb/trunk/source/API/SBTypeSummary.cpp

Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lldb.xcodeproj/project.pbxproj?rev=355458&r1=355457&r2=355458&view=diff
==
--- lldb/trunk/lldb.xcodeproj/project.pbxproj (original)
+++ lldb/trunk/lldb.xcodeproj/project.pbxproj Tue Mar  5 16:05:55 2019
@@ -3238,6 +3238,7 @@
9A4633DA11F65D8600955CE1 /* UserSettingsController.h */ = {isa 
= PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; name 
= UserSettingsController.h; path = include/lldb/Core/UserSettingsController.h; 
sourceTree = ""; };
4C00833F1B9F9BA900D5CF24 /* UtilityFunction.cpp */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; 
name = UtilityFunction.cpp; path = source/Expression/UtilityFunction.cpp; 
sourceTree = ""; };
4C00833D1B9F9B8400D5CF24 /* UtilityFunction.h */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; name = 
UtilityFunction.h; path = include/lldb/Expression/UtilityFunction.h; sourceTree 
= ""; };
+   DD54302F222F190D00C1F021 /* Utils.h */ = {isa = 
PBXFileReference; lastKnownFileType = sourcecode.c.h; name = Utils.h; path = 
source/API/Utils.h; sourceTree = ""; };
2654A6921E552F4600DA1013 /* VASPrintf.h */ = {isa = 
PBXFileReference; lastKnownFileType = sourcecode.c.h; name = VASPrintf.h; path 
= include/lldb/Utility/VASPrintf.h; sourceTree = ""; };
2654A68F1E552ED500DA1013 /* VASprintf.cpp */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; 
name = VASprintf.cpp; path = source/Utility/VASprintf.cpp; sourceTree = 
""; };
9A3D43C41F3150D200EB767C /* VASprintfTest.cpp */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; 
path = VASprintfTest.cpp; sourceTree = ""; };
@@ -4442,6 +4443,7 @@
23059A0F1958B319007B8189 /* SBUnixSignals.cpp 
*/,
9A19A6A51163BB7E00E0D453 /* SBValue.h */,
9A19A6AD1163BB9800E0D453 /* SBValue.cpp */,
+   DD54302F222F190D00C1F021 /* Utils.h */,
9A357582116CFDEE00E8ED2F /* SBValueList.h */,
9A35758D116CFE0F00E8ED2F /* SBValueList.cpp */,
94235B9A1A8D5FD800EB2EED /* 
SBVariablesOptions.h */,

Modified: lldb/trunk/source/API/SBAddress.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/API/SBAddress.cpp?rev=355458&r1=355457&r2=355458&view=diff
==
--- lldb/trunk/source/API/SBAddress.cpp (original)
+++ lldb/trunk/source/API/SBAddress.cpp Tue Mar  5 16:05:55 2019
@@ -7,6 +7,7 @@
 
//===-

[Lldb-commits] [PATCH] D58946: [SBAPI] Don't check IsValid in constructor

[Jonas Devlieghere via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL355458: [SBAPI] Don't check IsValid in constructor 
(authored by JDevlieghere, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D58946?vs=189377&id=189417#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58946/new/

https://reviews.llvm.org/D58946

Files:
  lldb/trunk/lldb.xcodeproj/project.pbxproj
  lldb/trunk/source/API/SBAddress.cpp
  lldb/trunk/source/API/SBAttachInfo.cpp
  lldb/trunk/source/API/SBCommandReturnObject.cpp
  lldb/trunk/source/API/SBDeclaration.cpp
  lldb/trunk/source/API/SBError.cpp
  lldb/trunk/source/API/SBExpressionOptions.cpp
  lldb/trunk/source/API/SBFileSpec.cpp
  lldb/trunk/source/API/SBFileSpecList.cpp
  lldb/trunk/source/API/SBFrame.cpp
  lldb/trunk/source/API/SBLineEntry.cpp
  lldb/trunk/source/API/SBMemoryRegionInfo.cpp
  lldb/trunk/source/API/SBModuleSpec.cpp
  lldb/trunk/source/API/SBProcessInfo.cpp
  lldb/trunk/source/API/SBStringList.cpp
  lldb/trunk/source/API/SBSymbolContext.cpp
  lldb/trunk/source/API/SBSymbolContextList.cpp
  lldb/trunk/source/API/SBThread.cpp
  lldb/trunk/source/API/SBTypeEnumMember.cpp
  lldb/trunk/source/API/SBTypeSummary.cpp
  lldb/trunk/source/API/Utils.h

Index: lldb/trunk/lldb.xcodeproj/project.pbxproj
===
--- lldb/trunk/lldb.xcodeproj/project.pbxproj
+++ lldb/trunk/lldb.xcodeproj/project.pbxproj
@@ -3238,6 +3238,7 @@
 		9A4633DA11F65D8600955CE1 /* UserSettingsController.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; name = UserSettingsController.h; path = include/lldb/Core/UserSettingsController.h; sourceTree = ""; };
 		4C00833F1B9F9BA900D5CF24 /* UtilityFunction.cpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; name = UtilityFunction.cpp; path = source/Expression/UtilityFunction.cpp; sourceTree = ""; };
 		4C00833D1B9F9B8400D5CF24 /* UtilityFunction.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; name = UtilityFunction.h; path = include/lldb/Expression/UtilityFunction.h; sourceTree = ""; };
+		DD54302F222F190D00C1F021 /* Utils.h */ = {isa = PBXFileReference; lastKnownFileType = sourcecode.c.h; name = Utils.h; path = source/API/Utils.h; sourceTree = ""; };
 		2654A6921E552F4600DA1013 /* VASPrintf.h */ = {isa = PBXFileReference; lastKnownFileType = sourcecode.c.h; name = VASPrintf.h; path = include/lldb/Utility/VASPrintf.h; sourceTree = ""; };
 		2654A68F1E552ED500DA1013 /* VASprintf.cpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; name = VASprintf.cpp; path = source/Utility/VASprintf.cpp; sourceTree = ""; };
 		9A3D43C41F3150D200EB767C /* VASprintfTest.cpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; path = VASprintfTest.cpp; sourceTree = ""; };
@@ -4442,6 +4443,7 @@
 23059A0F1958B319007B8189 /* SBUnixSignals.cpp */,
 9A19A6A51163BB7E00E0D453 /* SBValue.h */,
 9A19A6AD1163BB9800E0D453 /* SBValue.cpp */,
+DD54302F222F190D00C1F021 /* Utils.h */,
 9A357582116CFDEE00E8ED2F /* SBValueList.h */,
 9A35758D116CFE0F00E8ED2F /* SBValueList.cpp */,
 94235B9A1A8D5FD800EB2EED /* SBVariablesOptions.h */,
Index: lldb/trunk/source/API/SBSymbolContextList.cpp
===
--- lldb/trunk/source/API/SBSymbolContextList.cpp
+++ lldb/trunk/source/API/SBSymbolContextList.cpp
@@ -7,6 +7,7 @@
 //===--===//
 
 #include "lldb/API/SBSymbolContextList.h"
+#include "Utils.h"
 #include "lldb/API/SBStream.h"
 #include "lldb/Symbol/SymbolContext.h"
 
@@ -17,15 +18,17 @@
 : m_opaque_up(new SymbolContextList()) {}
 
 SBSymbolContextList::SBSymbolContextList(const SBSymbolContextList &rhs)
-: m_opaque_up(new SymbolContextList(*rhs.m_opaque_up)) {}
+: m_opaque_up() {
+
+  m_opaque_up = clone(rhs.m_opaque_up);
+}
 
 SBSymbolContextList::~SBSymbolContextList() {}
 
 const SBSymbolContextList &SBSymbolContextList::
 operator=(const SBSymbolContextList &rhs) {
-  if (this != &rhs) {
-*m_opaque_up = *rhs.m_opaque_up;
-  }
+  if (this != &rhs)
+m_opaque_up = clone(rhs.m_opaque_up);
   return *this;
 }
 
Index: lldb/trunk/source/API/SBStringList.cpp
===
--- lldb/trunk/source/API/SBStringList.cpp
+++ lldb/trunk/source/API/SBStringList.cpp
@@ -7,7 +7,7 @@
 //===--===//
 
 #include "lldb/API/SBStringList.h"
-
+#include "Utils.h"
 #include "lldb/Utility/StringList.h"
 
 using namespace lldb;
@@ -18,21 +18,16 @@
 SBStringList::SBStringList(const lldb_private::StringList *lldb_strings_ptr)
 : m_opaque_up() {
   if

[Lldb-commits] [PATCH] D57475: [Reproducers] Add SBReproducer macros

[Jonas Devlieghere via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rLLDB355459: [Reproducers] Add SBReproducer macros (authored 
by JDevlieghere, committed by ).
Herald added a subscriber: teemperor.

Changed prior to commit:
  https://reviews.llvm.org/D57475?vs=188015&id=189419#toc

Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57475/new/

https://reviews.llvm.org/D57475

Files:
  source/API/SBAddress.cpp
  source/API/SBAttachInfo.cpp
  source/API/SBBlock.cpp
  source/API/SBBreakpoint.cpp
  source/API/SBBreakpointLocation.cpp
  source/API/SBBreakpointName.cpp
  source/API/SBBroadcaster.cpp
  source/API/SBCommandInterpreter.cpp
  source/API/SBCommandReturnObject.cpp
  source/API/SBCommunication.cpp
  source/API/SBCompileUnit.cpp
  source/API/SBData.cpp
  source/API/SBDebugger.cpp
  source/API/SBDeclaration.cpp
  source/API/SBError.cpp
  source/API/SBEvent.cpp
  source/API/SBExecutionContext.cpp
  source/API/SBExpressionOptions.cpp
  source/API/SBFileSpec.cpp
  source/API/SBFileSpecList.cpp
  source/API/SBFrame.cpp
  source/API/SBFunction.cpp
  source/API/SBHostOS.cpp
  source/API/SBInstruction.cpp
  source/API/SBInstructionList.cpp
  source/API/SBLanguageRuntime.cpp
  source/API/SBLaunchInfo.cpp
  source/API/SBLineEntry.cpp
  source/API/SBListener.cpp
  source/API/SBMemoryRegionInfo.cpp
  source/API/SBMemoryRegionInfoList.cpp
  source/API/SBModule.cpp
  source/API/SBModuleSpec.cpp
  source/API/SBPlatform.cpp
  source/API/SBProcess.cpp
  source/API/SBProcessInfo.cpp
  source/API/SBQueue.cpp
  source/API/SBQueueItem.cpp
  source/API/SBReproducer.cpp
  source/API/SBSection.cpp
  source/API/SBSourceManager.cpp
  source/API/SBStream.cpp
  source/API/SBStringList.cpp
  source/API/SBStructuredData.cpp
  source/API/SBSymbol.cpp
  source/API/SBSymbolContext.cpp
  source/API/SBSymbolContextList.cpp
  source/API/SBTarget.cpp
  source/API/SBThread.cpp
  source/API/SBThreadCollection.cpp
  source/API/SBThreadPlan.cpp
  source/API/SBTrace.cpp
  source/API/SBTraceOptions.cpp
  source/API/SBType.cpp
  source/API/SBTypeCategory.cpp
  source/API/SBTypeEnumMember.cpp
  source/API/SBTypeFilter.cpp
  source/API/SBTypeFormat.cpp
  source/API/SBTypeNameSpecifier.cpp
  source/API/SBTypeSummary.cpp
  source/API/SBTypeSynthetic.cpp
  source/API/SBUnixSignals.cpp
  source/API/SBValue.cpp
  source/API/SBValueList.cpp
  source/API/SBVariablesOptions.cpp
  source/API/SBWatchpoint.cpp



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

[Lldb-commits] [PATCH] D59004: [lldb] Fix DW_OP_addrx uses.

[Ali Tamur via Phabricator via lldb-commits]

tamur updated this revision to Diff 189423.
tamur added a comment.
Herald added a reviewer: serge-sans-paille.

Added a test.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59004/new/

https://reviews.llvm.org/D59004

Files:
  lldb/packages/Python/lldbsuite/test/python_api/value/TestValueAPI.py
  lldb/source/Expression/DWARFExpression.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp
  lldb/source/Plugins/SymbolFile/DWARF/HashedNameToDIE.cpp

Index: lldb/source/Plugins/SymbolFile/DWARF/HashedNameToDIE.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/HashedNameToDIE.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/HashedNameToDIE.cpp
@@ -166,6 +166,7 @@
   case DW_FORM_ref_sig8:
 llvm_unreachable("Unhandled atom form");
 
+  case DW_FORM_addrx:
   case DW_FORM_string:
   case DW_FORM_block:
   case DW_FORM_block1:
Index: lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp
@@ -681,6 +681,7 @@
 return 1;
   switch (a_form) {
   case DW_FORM_addr:
+  case DW_FORM_addrx:
   case DW_FORM_flag:
   case DW_FORM_data1:
   case DW_FORM_data2:
Index: lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
@@ -326,6 +326,7 @@
 break;
 
   // signed or unsigned LEB 128 values
+  case DW_FORM_addrx:
   case DW_FORM_sdata:
   case DW_FORM_udata:
   case DW_FORM_ref_udata:
@@ -456,6 +457,7 @@
 
 case DW_AT_high_pc:
   if (form_value.Form() == DW_FORM_addr ||
+  form_value.Form() == DW_FORM_addrx ||
   form_value.Form() == DW_FORM_GNU_addr_index) {
 hi_pc = form_value.Address();
   } else {
@@ -1031,7 +1033,8 @@
   if (GetAttributeValue(dwarf2Data, cu, DW_AT_high_pc, form_value, nullptr,
 check_specification_or_abstract_origin)) {
 dw_form_t form = form_value.Form();
-if (form == DW_FORM_addr || form == DW_FORM_GNU_addr_index)
+if (form == DW_FORM_addr || form == DW_FORM_addrx ||
+form == DW_FORM_GNU_addr_index)
   return form_value.Address();
 
 // DWARF4 can specify the hi_pc as an 
Index: lldb/source/Expression/DWARFExpression.cpp
===
--- lldb/source/Expression/DWARFExpression.cpp
+++ lldb/source/Expression/DWARFExpression.cpp
@@ -514,6 +514,10 @@
   s->Printf("DW_OP_GNU_addr_index(0x%" PRIx64 ")",
 m_data.GetULEB128(&offset));
   break;
+case DW_OP_addrx:
+  s->Printf("DW_OP_addrx(0x%" PRIx64 ")",
+m_data.GetULEB128(&offset));
+  break;
 case DW_OP_GNU_const_index: // 0xfc
   s->Printf("DW_OP_GNU_const_index(0x%" PRIx64 ")",
 m_data.GetULEB128(&offset));
@@ -877,6 +881,7 @@
 return 8;
 
   // All opcodes that have a single ULEB (signed or unsigned) argument
+  case DW_OP_addrx:   // 0xa1 1 ULEB128 index
   case DW_OP_constu:  // 0x10 1 ULEB128 constant
   case DW_OP_consts:  // 0x11 1 SLEB128 constant
   case DW_OP_plus_uconst: // 0x23 1 ULEB128 addend
@@ -957,7 +962,7 @@
 return op_file_addr;
   else
 ++curr_op_addr_idx;
-} else if (op == DW_OP_GNU_addr_index) {
+} else if (op == DW_OP_GNU_addr_index || op == DW_OP_addrx) {
   uint64_t index = m_data.GetULEB128(&offset);
   if (curr_op_addr_idx == op_addr_idx) {
 if (!m_dwarf_cu) {
@@ -2902,13 +2907,14 @@
 } break;
 
 //--
-// OPCODE: DW_OP_GNU_addr_index
+// OPCODE: DW_OP_addrx (DW_OP_GNU_addr_index is the legacy name.)
 // OPERANDS: 1
 //  ULEB128: index to the .debug_addr section
 // DESCRIPTION: Pushes an address to the stack from the .debug_addr
 // section with the base address specified by the DW_AT_addr_base attribute
 // and the 0 based index is the ULEB128 encoded index.
 //--
+case DW_OP_addrx:
 case DW_OP_GNU_addr_index: {
   if (!dwarf_cu) {
 if (error_ptr)
@@ -3194,6 +3200,7 @@
   case DW_OP_call_ref:
 size = dwarf_ref_size;
 break;
+  case DW_OP_addrx:
   case DW_OP_piece:
   case DW_OP_plus_uconst:
   case DW_OP_regx:
Index: lldb/packages/Python/lldbsuite/test/python_api/value/TestValueAPI.py
===
--- lldb/packages/

[Lldb-commits] [lldb] r355463 - [ExpressionParser] Test GetClangResourceDir

[Alex Langford via lldb-commits]

Author: xiaobai
Date: Tue Mar  5 16:45:16 2019
New Revision: 355463

URL: http://llvm.org/viewvc/llvm-project?rev=355463&view=rev
Log:
[ExpressionParser] Test GetClangResourceDir

Summary:
I'm doing this because I plan on implementing `ComputeClangResourceDirectory`
on windows so that `GetClangResourceDir` will work.  Additionally, I made
test_paths make sure that the directory member of the returned FileSpec is not
none. This will fail on windows since `ComputeClangResourceDirectory` isn't
implemented yet.

Differential Revision: https://reviews.llvm.org/D58748

Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/paths/TestPaths.py
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangHost.cpp
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangHost.h
lldb/trunk/unittests/Expression/ClangParserTest.cpp

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/paths/TestPaths.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/paths/TestPaths.py?rev=355463&r1=355462&r2=355463&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/paths/TestPaths.py 
(original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/paths/TestPaths.py 
Tue Mar  5 16:45:16 2019
@@ -32,6 +32,15 @@ class TestPaths(TestBase):
 # No directory path types should have the filename set
 self.assertTrue(f.GetFilename() is None)
 
+# TODO: Merge into test_path when GetClangResourceDir is implemented on
+# windows
+@expectedFailureAll(oslist=["windows"])
+@no_debug_info_test
+def test_clang_dir_path(self):
+  '''Test to make sure clang dir is set correctly'''
+  clang_dir = lldb.SBHostOS.GetLLDBPath(lldb.ePathTypeClangDir)
+  self.assertFalse(clang_dir.GetDirectory() is None)
+
 @no_debug_info_test
 def test_directory_doesnt_end_with_slash(self):
 current_directory_spec = lldb.SBFileSpec(os.path.curdir)

Modified: lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangHost.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangHost.cpp?rev=355463&r1=355462&r2=355463&view=diff
==
--- lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangHost.cpp (original)
+++ lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangHost.cpp Tue Mar  5 
16:45:16 2019
@@ -29,17 +29,8 @@
 using namespace lldb_private;
 
 #if defined(_WIN32)
-static bool ComputeClangDirectory(FileSpec &file_spec) { return false; }
+static bool ComputeClangResourceDirectory(FileSpec &file_spec) { return false; 
}
 #else
-static bool DefaultComputeClangDirectory(FileSpec &file_spec) {
-  return HostInfoPosix::ComputePathRelativeToLibrary(
-  file_spec, (llvm::Twine("/lib") + CLANG_LIBDIR_SUFFIX + "/clang/" +
-  CLANG_VERSION_STRING)
- .str());
-}
-
-#if defined(__APPLE__)
-
 static bool VerifyClangPath(const llvm::Twine &clang_path) {
   if (FileSystem::Instance().IsDirectory(clang_path))
 return true;
@@ -51,9 +42,38 @@ static bool VerifyClangPath(const llvm::
   return false;
 }
 
-bool lldb_private::ComputeClangDirectory(FileSpec &lldb_shlib_spec,
+///
+/// This will compute the clang resource directory assuming that clang was
+/// installed with the same prefix as lldb.
+///
+static bool DefaultComputeClangResourceDirectory(FileSpec &lldb_shlib_spec,
  FileSpec &file_spec, bool verify) {
   std::string raw_path = lldb_shlib_spec.GetPath();
+  llvm::StringRef parent_dir = llvm::sys::path::parent_path(raw_path);
+
+  llvm::SmallString<256> clang_dir(parent_dir);
+  llvm::SmallString<32> relative_path;
+  llvm::sys::path::append(relative_path,
+  llvm::Twine("lib") + CLANG_LIBDIR_SUFFIX, "clang",
+  CLANG_VERSION_STRING);
+
+  llvm::sys::path::append(clang_dir, relative_path);
+  if (!verify || VerifyClangPath(clang_dir)) {
+file_spec.GetDirectory().SetString(clang_dir);
+FileSystem::Instance().Resolve(file_spec);
+return true;
+  }
+
+  return HostInfoPosix::ComputePathRelativeToLibrary(file_spec, relative_path);
+}
+
+bool lldb_private::ComputeClangResourceDirectory(FileSpec &lldb_shlib_spec,
+ FileSpec &file_spec, bool verify) {
+#if !defined(__APPLE__)
+  return DefaultComputeClangResourceDirectory(lldb_shlib_spec, file_spec,
+  verify);
+#else
+  std::string raw_path = lldb_shlib_spec.GetPath();
 
   auto rev_it = llvm::sys::path::rbegin(raw_path);
   auto r_end = llvm::sys::path::rend(raw_path);
@@ -65,8 +85,10 @@ bool lldb_private::ComputeClangDirectory
 ++rev_it;
   }
 
+  // Posix-style of LLDB detected.
   if (rev_it == r_end)
-return DefaultComputeC

[Lldb-commits] [PATCH] D58748: [ExpressionParser] Test GetClangResourceDir

[Alex Langford via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rLLDB355463: [ExpressionParser] Test GetClangResourceDir 
(authored by xiaobai, committed by ).
Herald added a project: LLDB.

Changed prior to commit:
  https://reviews.llvm.org/D58748?vs=189392&id=189427#toc

Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58748/new/

https://reviews.llvm.org/D58748

Files:
  packages/Python/lldbsuite/test/functionalities/paths/TestPaths.py
  source/Plugins/ExpressionParser/Clang/ClangHost.cpp
  source/Plugins/ExpressionParser/Clang/ClangHost.h
  unittests/Expression/ClangParserTest.cpp

Index: packages/Python/lldbsuite/test/functionalities/paths/TestPaths.py
===
--- packages/Python/lldbsuite/test/functionalities/paths/TestPaths.py
+++ packages/Python/lldbsuite/test/functionalities/paths/TestPaths.py
@@ -32,6 +32,15 @@
 # No directory path types should have the filename set
 self.assertTrue(f.GetFilename() is None)
 
+# TODO: Merge into test_path when GetClangResourceDir is implemented on
+# windows
+@expectedFailureAll(oslist=["windows"])
+@no_debug_info_test
+def test_clang_dir_path(self):
+  '''Test to make sure clang dir is set correctly'''
+  clang_dir = lldb.SBHostOS.GetLLDBPath(lldb.ePathTypeClangDir)
+  self.assertFalse(clang_dir.GetDirectory() is None)
+
 @no_debug_info_test
 def test_directory_doesnt_end_with_slash(self):
 current_directory_spec = lldb.SBFileSpec(os.path.curdir)
Index: unittests/Expression/ClangParserTest.cpp
===
--- unittests/Expression/ClangParserTest.cpp
+++ unittests/Expression/ClangParserTest.cpp
@@ -6,6 +6,8 @@
 //
 //===--===//
 
+#include "clang/Basic/Version.h"
+
 #include "Plugins/ExpressionParser/Clang/ClangHost.h"
 #include "TestingSupport/TestUtilities.h"
 #include "lldb/Host/FileSystem.h"
@@ -29,32 +31,44 @@
 };
 } // namespace
 
-#ifdef __APPLE__
-static std::string ComputeClangDir(std::string lldb_shlib_path,
-   bool verify = false) {
+#if !defined(_WIN32)
+static std::string ComputeClangResourceDir(std::string lldb_shlib_path,
+   bool verify = false) {
   FileSpec clang_dir;
   FileSpec lldb_shlib_spec(lldb_shlib_path);
-  ComputeClangDirectory(lldb_shlib_spec, clang_dir, verify);
+  ComputeClangResourceDirectory(lldb_shlib_spec, clang_dir, verify);
   return clang_dir.GetPath();
 }
 
+TEST_F(ClangHostTest, ComputeClangResourceDirectory) {
+  std::string path_to_liblldb = "/foo/bar/lib/";
+  std::string path_to_clang_dir = "/foo/bar/lib/clang/" CLANG_VERSION_STRING;
+  EXPECT_EQ(ComputeClangResourceDir(path_to_liblldb), path_to_clang_dir);
+
+  // The path doesn't really exist, so setting verify to true should make
+  // ComputeClangResourceDir to not give you path_to_clang_dir.
+  EXPECT_NE(ComputeClangResourceDir(path_to_liblldb, true),
+ComputeClangResourceDir(path_to_liblldb));
+}
+
+#if defined(__APPLE__)
 TEST_F(ClangHostTest, MacOSX) {
   // This returns whatever the POSIX fallback returns.
   std::string posix = "/usr/lib/liblldb.dylib";
-  EXPECT_FALSE(ComputeClangDir(posix).empty());
+  EXPECT_FALSE(ComputeClangResourceDir(posix).empty());
 
   std::string build =
   "/lldb-macosx-x86_64/Library/Frameworks/LLDB.framework/Versions/A";
   std::string build_clang =
   "/lldb-macosx-x86_64/Library/Frameworks/LLDB.framework/Resources/Clang";
-  EXPECT_EQ(ComputeClangDir(build), build_clang);
+  EXPECT_EQ(ComputeClangResourceDir(build), build_clang);
 
   std::string xcode = "/Applications/Xcode.app/Contents/SharedFrameworks/"
   "LLDB.framework/Versions/A";
   std::string xcode_clang =
   "/Applications/Xcode.app/Contents/Developer/Toolchains/"
   "XcodeDefault.xctoolchain/usr/lib/swift/clang";
-  EXPECT_EQ(ComputeClangDir(xcode), xcode_clang);
+  EXPECT_EQ(ComputeClangResourceDir(xcode), xcode_clang);
 
   std::string toolchain =
   "/Applications/Xcode.app/Contents/Developer/Toolchains/"
@@ -63,17 +77,18 @@
   std::string toolchain_clang =
   "/Applications/Xcode.app/Contents/Developer/Toolchains/"
   "Swift-4.1-development-snapshot.xctoolchain/usr/lib/swift/clang";
-  EXPECT_EQ(ComputeClangDir(toolchain), toolchain_clang);
+  EXPECT_EQ(ComputeClangResourceDir(toolchain), toolchain_clang);
 
   std::string cltools = "/Library/Developer/CommandLineTools/Library/"
 "PrivateFrameworks/LLDB.framework";
   std::string cltools_clang =
   "/Library/Developer/CommandLineTools/Library/PrivateFrameworks/"
   "LLDB.framework/Resources/Clang";
-  EXPECT_EQ(ComputeClangDir(cltools), cltools_clang);
+  EXPECT_EQ(ComputeClangResourceDir(cltools), cltools_clang);
 
   // Test that a bogus p

[Lldb-commits] [lldb] r355464 - [Reproducers] Fix warnings without asserts

[Jonas Devlieghere via lldb-commits]

Author: jdevlieghere
Date: Tue Mar  5 16:52:48 2019
New Revision: 355464

URL: http://llvm.org/viewvc/llvm-project?rev=355464&view=rev
Log:
[Reproducers] Fix warnings without asserts

Make sure the variable is used when asserts are compiled out.

Modified:
lldb/trunk/include/lldb/Utility/ReproducerInstrumentation.h

Modified: lldb/trunk/include/lldb/Utility/ReproducerInstrumentation.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Utility/ReproducerInstrumentation.h?rev=355464&r1=355463&r2=355464&view=diff
==
--- lldb/trunk/include/lldb/Utility/ReproducerInstrumentation.h (original)
+++ lldb/trunk/include/lldb/Utility/ReproducerInstrumentation.h Tue Mar  5 
16:52:48 2019
@@ -261,6 +261,7 @@ public:
   void HandleReplayResultVoid() {
 unsigned result = Deserialize();
 assert(result == 0);
+(void)result;
   }
 
 private:


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

[Lldb-commits] [lldb] r355465 - [Reproducers] Undef LLDB_REPRO_INSTR_TRACE

[Jonas Devlieghere via lldb-commits]

Author: jdevlieghere
Date: Tue Mar  5 17:00:36 2019
New Revision: 355465

URL: http://llvm.org/viewvc/llvm-project?rev=355465&view=rev
Log:
[Reproducers] Undef LLDB_REPRO_INSTR_TRACE

Forgot to undef this before landing.

Modified:
lldb/trunk/include/lldb/Utility/ReproducerInstrumentation.h

Modified: lldb/trunk/include/lldb/Utility/ReproducerInstrumentation.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Utility/ReproducerInstrumentation.h?rev=355465&r1=355464&r2=355465&view=diff
==
--- lldb/trunk/include/lldb/Utility/ReproducerInstrumentation.h (original)
+++ lldb/trunk/include/lldb/Utility/ReproducerInstrumentation.h Tue Mar  5 
17:00:36 2019
@@ -21,7 +21,7 @@
 // Define LLDB_REPRO_INSTR_TRACE to trace to stderr instead of LLDB's log
 // infrastructure. This is useful when you need to see traces before the logger
 // is initialized or enabled.
-#define LLDB_REPRO_INSTR_TRACE
+// #define LLDB_REPRO_INSTR_TRACE
 
 #define LLDB_REGISTER_CONSTRUCTOR(Class, Signature)
\
   Register(&construct::doit, "", #Class,   
\


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

[Lldb-commits] [lldb] r355466 - Replace debug-only assert with a plain old assert.

[Adrian Prantl via lldb-commits]

Author: adrian
Date: Tue Mar  5 17:07:45 2019
New Revision: 355466

URL: http://llvm.org/viewvc/llvm-project?rev=355466&view=rev
Log:
Replace debug-only assert with a plain old assert.

Modified:
lldb/trunk/source/Interpreter/CommandObject.cpp

Modified: lldb/trunk/source/Interpreter/CommandObject.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Interpreter/CommandObject.cpp?rev=355466&r1=355465&r2=355466&view=diff
==
--- lldb/trunk/source/Interpreter/CommandObject.cpp (original)
+++ lldb/trunk/source/Interpreter/CommandObject.cpp Tue Mar  5 17:07:45 2019
@@ -136,17 +136,15 @@ bool CommandObject::ParseOptions(Args &a
 }
 
 bool CommandObject::CheckRequirements(CommandReturnObject &result) {
-#ifdef LLDB_CONFIGURATION_DEBUG
   // Nothing should be stored in m_exe_ctx between running commands as
   // m_exe_ctx has shared pointers to the target, process, thread and frame and
   // we don't want any CommandObject instances to keep any of these objects
   // around longer than for a single command. Every command should call
-  // CommandObject::Cleanup() after it has completed
-  assert(m_exe_ctx.GetTargetPtr() == NULL);
-  assert(m_exe_ctx.GetProcessPtr() == NULL);
-  assert(m_exe_ctx.GetThreadPtr() == NULL);
-  assert(m_exe_ctx.GetFramePtr() == NULL);
-#endif
+  // CommandObject::Cleanup() after it has completed.
+  assert(!m_exe_ctx.GetTargetPtr());
+  assert(!m_exe_ctx.GetProcessPtr());
+  assert(!m_exe_ctx.GetThreadPtr());
+  assert(!m_exe_ctx.GetFramePtr());
 
   // Lock down the interpreter's execution context prior to running the command
   // so we guarantee the selected target, process, thread and frame can't go


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

[Lldb-commits] [PATCH] D58930: Add XCOFF triple object format type for AIX

[Hubert Tong via Phabricator via lldb-commits]

hubert.reinterpretcast added inline comments.



Comment at: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp:2079
+  if (log)
+log->Printf("sorry: unimplemented for XCOFF");
+  return false;

JDevlieghere wrote:
> jasonliu wrote:
> > JDevlieghere wrote:
> > > jasonliu wrote:
> > > > apaprocki wrote:
> > > > > No need to be `sorry:` :) This should probably just say `error: XCOFF 
> > > > > is unimplemented` to be more direct in case anything is expecting 
> > > > > "error:" in the output.
> > > > Sure. Will address in next revision.
> > > Just bundle this with the WASM case, the error message is correct for 
> > > both.
> > I think they are different. 
> > The error message for WASM seems to suggest that it will never ever get 
> > supported on WASM. 
> > But it is not the case for XCOFF, we want to indicate that it is not 
> > implemented yet.  
> I don't think the error message suggests that at all, and it's definitely not 
> true. At this point neither XCOFF nor WASM is supported, and that's exactly 
> what the log message says.
> 
I agree that the error message for WASM does not indicate that the lack of 
support is inherent or intended to be permanent; however, it is not indicative 
either of an intent to implement the support. I am not sure what the intent is 
for WASM, but I do know that the intent for XCOFF is to eventually implement 
the support. I do not see how using an ambiguous message in this commit (when 
we know what the intent is) is superior to the alternative of having an 
unambiguous message.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58930/new/

https://reviews.llvm.org/D58930



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

[Lldb-commits] [PATCH] D58748: [ExpressionParser] Test GetClangResourceDir

[Stella Stamenova via Phabricator via lldb-commits]

stella.stamenova added a comment.

This introduced a build break on Windows (which happened to coincide with 
another build break).

http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/2317


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58748/new/

https://reviews.llvm.org/D58748



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

[Lldb-commits] [lldb] r355469 - [Reproducers] Don't intercept SBDebugger::SetInputFileHandle

[Jonas Devlieghere via lldb-commits]

Author: jdevlieghere
Date: Tue Mar  5 17:49:54 2019
New Revision: 355469

URL: http://llvm.org/viewvc/llvm-project?rev=355469&view=rev
Log:
[Reproducers] Don't intercept SBDebugger::SetInputFileHandle

With the reproducer logic in place for the command interpreter we no
longer need to make SBDebugger::SetInputFileHandle a no-op.

Modified:
lldb/trunk/source/API/SBReproducer.cpp

Modified: lldb/trunk/source/API/SBReproducer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/API/SBReproducer.cpp?rev=355469&r1=355468&r2=355469&view=diff
==
--- lldb/trunk/source/API/SBReproducer.cpp (original)
+++ lldb/trunk/source/API/SBReproducer.cpp Tue Mar  5 17:49:54 2019
@@ -45,9 +45,6 @@ SBRegistry::SBRegistry() {
 
   // Custom implementation.
   Register(&invoke::method<&SBDebugger::SetInputFileHandle>::doit,
-   &SetFileHandleRedirect);
-  Register(&invoke::method<&SBDebugger::SetErrorFileHandle>::doit,
&SetFileHandleRedirect);
   Register(&invokehttps://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r355470 - [Reproducers] Enable replay from SBRepro.

[Jonas Devlieghere via lldb-commits]

Author: jdevlieghere
Date: Tue Mar  5 17:49:57 2019
New Revision: 355470

URL: http://llvm.org/viewvc/llvm-project?rev=355470&view=rev
Log:
[Reproducers] Enable replay from SBRepro.

Now that the LLDB instrumentation macros are in place, we should use
that to test reproducer replay.

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

Removed:
lldb/trunk/lit/Reproducer/Inputs/FileReplay.in
lldb/trunk/lit/Reproducer/Inputs/GDBRemoteReplay.in
Modified:
lldb/trunk/lit/Reproducer/TestFileRepro.test
lldb/trunk/lit/Reproducer/TestGDBRemoteRepro.test
lldb/trunk/source/API/SBReproducer.cpp
lldb/trunk/tools/driver/Driver.cpp

Removed: lldb/trunk/lit/Reproducer/Inputs/FileReplay.in
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Reproducer/Inputs/FileReplay.in?rev=355469&view=auto
==
--- lldb/trunk/lit/Reproducer/Inputs/FileReplay.in (original)
+++ lldb/trunk/lit/Reproducer/Inputs/FileReplay.in (removed)
@@ -1,2 +0,0 @@
-reproducer status
-run

Removed: lldb/trunk/lit/Reproducer/Inputs/GDBRemoteReplay.in
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Reproducer/Inputs/GDBRemoteReplay.in?rev=355469&view=auto
==
--- lldb/trunk/lit/Reproducer/Inputs/GDBRemoteReplay.in (original)
+++ lldb/trunk/lit/Reproducer/Inputs/GDBRemoteReplay.in (removed)
@@ -1,5 +0,0 @@
-reproducer status
-breakpoint set -f simple.c -l 12
-run
-bt
-cont

Modified: lldb/trunk/lit/Reproducer/TestFileRepro.test
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Reproducer/TestFileRepro.test?rev=355470&r1=355469&r2=355470&view=diff
==
--- lldb/trunk/lit/Reproducer/TestFileRepro.test (original)
+++ lldb/trunk/lit/Reproducer/TestFileRepro.test Tue Mar  5 17:49:57 2019
@@ -7,9 +7,9 @@
 # that the string "testing" is not printed.
 
 # RUN: %clang %S/Inputs/simple.c -g -o %t.out
-# RUN: %lldb -x -b -s %S/Inputs/FileCapture.in --capture %t.repro -- %t.out | 
FileCheck %s --check-prefix CHECK --check-prefix CAPTURE
+# RUN: %lldb -x -b -s %S/Inputs/FileCapture.in --capture %t.repro %t.out | 
FileCheck %s --check-prefix CHECK --check-prefix CAPTURE
 # RUN: rm %t.out
-# RUN: %lldb -x -b -s %S/Inputs/FileReplay.in --replay %t.repro -- %t.out | 
FileCheck %s --check-prefix CHECK --check-prefix REPLAY
+# RUN: %lldb --replay %t.repro | FileCheck %s --check-prefix CHECK 
--check-prefix REPLAY
 
 # CAPTURE: testing
 # REPLAY-NOT: testing

Modified: lldb/trunk/lit/Reproducer/TestGDBRemoteRepro.test
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Reproducer/TestGDBRemoteRepro.test?rev=355470&r1=355469&r2=355470&view=diff
==
--- lldb/trunk/lit/Reproducer/TestGDBRemoteRepro.test (original)
+++ lldb/trunk/lit/Reproducer/TestGDBRemoteRepro.test Tue Mar  5 17:49:57 2019
@@ -7,8 +7,8 @@
 # that the string "testing" is not printed.
 
 # RUN: %clang %S/Inputs/simple.c -g -o %t.out
-# RUN: %lldb -x -b -s %S/Inputs/GDBRemoteCapture.in --capture %t.repro -- 
%t.out | FileCheck %s --check-prefix CHECK --check-prefix CAPTURE
-# RUN: %lldb -x -b -s %S/Inputs/GDBRemoteReplay.in --replay %t.repro -- %t.out 
| FileCheck %s --check-prefix CHECK --check-prefix REPLAY
+# RUN: %lldb -x -b -s %S/Inputs/GDBRemoteCapture.in --capture %t.repro %t.out 
| FileCheck %s --check-prefix CHECK --check-prefix CAPTURE
+# RUN: %lldb --replay %t.repro | FileCheck %s --check-prefix CHECK 
--check-prefix REPLAY
 
 # CHECK: Breakpoint 1
 # CHECK: Process {{.*}} stopped

Modified: lldb/trunk/source/API/SBReproducer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/API/SBReproducer.cpp?rev=355470&r1=355469&r2=355470&view=diff
==
--- lldb/trunk/source/API/SBReproducer.cpp (original)
+++ lldb/trunk/source/API/SBReproducer.cpp Tue Mar  5 17:49:57 2019
@@ -2901,8 +2901,6 @@ const char *SBReproducer::Replay(const c
 return error.c_str();
   }
 
-  // FIXME: Enable the following code once the SB reproducer has landed.
-#if 0
   FileSpec file = loader->GetFile();
   if (!file) {
 error = "unable to get replay data from reproducer.";
@@ -2911,7 +2909,6 @@ const char *SBReproducer::Replay(const c
 
   SBRegistry registry;
   registry.Replay(file);
-#endif
 
   return nullptr;
 }

Modified: lldb/trunk/tools/driver/Driver.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/driver/Driver.cpp?rev=355470&r1=355469&r2=355470&view=diff
==
--- lldb/trunk/tools/driver/Driver.cpp (original)
+++ lldb/trunk/tools/driver/Driver.cpp Tue Mar  5 17:49:57 2019
@@ -905,7 +905,7 @@ main(int argc, char const *argv[])
   WithColor::error() << "reproducer replay failed: " << error << '\n';

[Lldb-commits] [PATCH] D58565: [Reproducers] Enable replay from SBRepro

[Jonas Devlieghere via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rLLDB355470: [Reproducers] Enable replay from SBRepro. 
(authored by JDevlieghere, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D58565?vs=188016&id=189432#toc

Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58565/new/

https://reviews.llvm.org/D58565

Files:
  lit/Reproducer/Inputs/FileReplay.in
  lit/Reproducer/Inputs/GDBRemoteReplay.in
  lit/Reproducer/TestFileRepro.test
  lit/Reproducer/TestGDBRemoteRepro.test
  source/API/SBReproducer.cpp
  tools/driver/Driver.cpp


Index: tools/driver/Driver.cpp
===
--- tools/driver/Driver.cpp
+++ tools/driver/Driver.cpp
@@ -905,7 +905,7 @@
   WithColor::error() << "reproducer replay failed: " << error << '\n';
   return 1;
 }
-// FIXME: Return once SBReproducer::Replay actually performs the replay.
+return 0;
   }
 
   SBError error = SBDebugger::InitializeWithErrorHandling();
Index: source/API/SBReproducer.cpp
===
--- source/API/SBReproducer.cpp
+++ source/API/SBReproducer.cpp
@@ -2901,8 +2901,6 @@
 return error.c_str();
   }
 
-  // FIXME: Enable the following code once the SB reproducer has landed.
-#if 0
   FileSpec file = loader->GetFile();
   if (!file) {
 error = "unable to get replay data from reproducer.";
@@ -2911,7 +2909,6 @@
 
   SBRegistry registry;
   registry.Replay(file);
-#endif
 
   return nullptr;
 }
Index: lit/Reproducer/TestGDBRemoteRepro.test
===
--- lit/Reproducer/TestGDBRemoteRepro.test
+++ lit/Reproducer/TestGDBRemoteRepro.test
@@ -7,8 +7,8 @@
 # that the string "testing" is not printed.
 
 # RUN: %clang %S/Inputs/simple.c -g -o %t.out
-# RUN: %lldb -x -b -s %S/Inputs/GDBRemoteCapture.in --capture %t.repro -- 
%t.out | FileCheck %s --check-prefix CHECK --check-prefix CAPTURE
-# RUN: %lldb -x -b -s %S/Inputs/GDBRemoteReplay.in --replay %t.repro -- %t.out 
| FileCheck %s --check-prefix CHECK --check-prefix REPLAY
+# RUN: %lldb -x -b -s %S/Inputs/GDBRemoteCapture.in --capture %t.repro %t.out 
| FileCheck %s --check-prefix CHECK --check-prefix CAPTURE
+# RUN: %lldb --replay %t.repro | FileCheck %s --check-prefix CHECK 
--check-prefix REPLAY
 
 # CHECK: Breakpoint 1
 # CHECK: Process {{.*}} stopped
Index: lit/Reproducer/TestFileRepro.test
===
--- lit/Reproducer/TestFileRepro.test
+++ lit/Reproducer/TestFileRepro.test
@@ -7,9 +7,9 @@
 # that the string "testing" is not printed.
 
 # RUN: %clang %S/Inputs/simple.c -g -o %t.out
-# RUN: %lldb -x -b -s %S/Inputs/FileCapture.in --capture %t.repro -- %t.out | 
FileCheck %s --check-prefix CHECK --check-prefix CAPTURE
+# RUN: %lldb -x -b -s %S/Inputs/FileCapture.in --capture %t.repro %t.out | 
FileCheck %s --check-prefix CHECK --check-prefix CAPTURE
 # RUN: rm %t.out
-# RUN: %lldb -x -b -s %S/Inputs/FileReplay.in --replay %t.repro -- %t.out | 
FileCheck %s --check-prefix CHECK --check-prefix REPLAY
+# RUN: %lldb --replay %t.repro | FileCheck %s --check-prefix CHECK 
--check-prefix REPLAY
 
 # CAPTURE: testing
 # REPLAY-NOT: testing
Index: lit/Reproducer/Inputs/FileReplay.in
===
--- lit/Reproducer/Inputs/FileReplay.in
+++ lit/Reproducer/Inputs/FileReplay.in
@@ -1,2 +0,0 @@
-reproducer status
-run
Index: lit/Reproducer/Inputs/GDBRemoteReplay.in
===
--- lit/Reproducer/Inputs/GDBRemoteReplay.in
+++ lit/Reproducer/Inputs/GDBRemoteReplay.in
@@ -1,5 +0,0 @@
-reproducer status
-breakpoint set -f simple.c -l 12
-run
-bt
-cont


Index: tools/driver/Driver.cpp
===
--- tools/driver/Driver.cpp
+++ tools/driver/Driver.cpp
@@ -905,7 +905,7 @@
   WithColor::error() << "reproducer replay failed: " << error << '\n';
   return 1;
 }
-// FIXME: Return once SBReproducer::Replay actually performs the replay.
+return 0;
   }
 
   SBError error = SBDebugger::InitializeWithErrorHandling();
Index: source/API/SBReproducer.cpp
===
--- source/API/SBReproducer.cpp
+++ source/API/SBReproducer.cpp
@@ -2901,8 +2901,6 @@
 return error.c_str();
   }
 
-  // FIXME: Enable the following code once the SB reproducer has landed.
-#if 0
   FileSpec file = loader->GetFile();
   if (!file) {
 error = "unable to get replay data from reproducer.";
@@ -2911,7 +2909,6 @@
 
   SBRegistry registry;
   registry.Replay(file);
-#endif
 
   return nullptr;
 }
Index: lit/Reproducer/TestGDBRemoteRepro.test
===
--- lit/Reproducer/TestGDBRemoteRepro.test
+++ lit/Reproducer/TestGDBRemoteRepro.test

[Lldb-commits] [lldb] r355471 - [ExpressionParser] Fix ComputeClangResourceDirectory for windows

[Alex Langford via lldb-commits]

Author: xiaobai
Date: Tue Mar  5 17:57:04 2019
New Revision: 355471

URL: http://llvm.org/viewvc/llvm-project?rev=355471&view=rev
Log:
[ExpressionParser] Fix ComputeClangResourceDirectory for windows

The function signature of ComputeClangResourceDirectory for windows
wasn't updated when the others changed, causing the windows build to
fail. This should fix that.

Modified:
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangHost.cpp

Modified: lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangHost.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangHost.cpp?rev=355471&r1=355470&r2=355471&view=diff
==
--- lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangHost.cpp (original)
+++ lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangHost.cpp Tue Mar  5 
17:57:04 2019
@@ -29,7 +29,10 @@
 using namespace lldb_private;
 
 #if defined(_WIN32)
-static bool ComputeClangResourceDirectory(FileSpec &file_spec) { return false; 
}
+static bool ComputeClangResourceDirectory(FileSpec &lldb_shlib_spec,
+  FileSpec &file_spec, bool verify) {
+  return false;
+}
 #else
 static bool VerifyClangPath(const llvm::Twine &clang_path) {
   if (FileSystem::Instance().IsDirectory(clang_path))


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

[Lldb-commits] [lldb] r355473 - Re-commit logging for SBCompileUnit::GetNumLineEntries.

[Jason Molenda via lldb-commits]

Author: jmolenda
Date: Tue Mar  5 18:32:45 2019
New Revision: 355473

URL: http://llvm.org/viewvc/llvm-project?rev=355473&view=rev
Log:
Re-commit logging for SBCompileUnit::GetNumLineEntries.

Modified:
lldb/trunk/source/API/SBCompileUnit.cpp

Modified: lldb/trunk/source/API/SBCompileUnit.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/API/SBCompileUnit.cpp?rev=355473&r1=355472&r2=355473&view=diff
==
--- lldb/trunk/source/API/SBCompileUnit.cpp (original)
+++ lldb/trunk/source/API/SBCompileUnit.cpp Tue Mar  5 18:32:45 2019
@@ -57,10 +57,16 @@ SBFileSpec SBCompileUnit::GetFileSpec()
 uint32_t SBCompileUnit::GetNumLineEntries() const {
   LLDB_RECORD_METHOD_CONST_NO_ARGS(uint32_t, SBCompileUnit, GetNumLineEntries);
 
+  Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_API));
   if (m_opaque_ptr) {
 LineTable *line_table = m_opaque_ptr->GetLineTable();
-if (line_table)
+if (line_table) {
+  if (log)
+log->Printf("SBCompileUnit(%p)::GetNumLineEntries() => %d",
+static_cast(m_opaque_ptr),
+(int)line_table->GetSize());
   return line_table->GetSize();
+}
   }
   return 0;
 }


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

[Lldb-commits] [lldb] r355476 - Change the scanning algorithm in DynamicLoaderDarwinKernel::SearchForKernelNearPC.

[Jason Molenda via lldb-commits]

Author: jmolenda
Date: Tue Mar  5 18:45:27 2019
New Revision: 355476

URL: http://llvm.org/viewvc/llvm-project?rev=355476&view=rev
Log:
Change the scanning algorithm in 
DynamicLoaderDarwinKernel::SearchForKernelNearPC.
Currently when lldb might be doing a kernel debug session, it scans through
memory by taking the current pc value and looking for a kernel at megabyte
boundaries, up to 32MB behind $pc.  This adjusts the algorithm to
scan back at every 16k page boundary and to stop scanning as soon
as we hit a memory read error.  The addition of stopping at a memory read
error saves us from tons of unnecessary packet traffic on generic 
targets where lldb might look for a kernel binary.

I've been trying to think of how to construct a test for this; it's a bit
tricky.  A gdb-remote protocol test with the contents of a fake tiny kernel
mach-o binary would satisify part of it, but this kernel path also directly
calls over to dsymForUUID or DebugSymbols framework lookups to find the 
kernel binary as well.  I'll keep thinking about this one, but it's so
intertangled with these two external systems that it may be hard to do.

 


Modified:

lldb/trunk/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp

lldb/trunk/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.h

Modified: 
lldb/trunk/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp?rev=355476&r1=355475&r2=355476&view=diff
==
--- 
lldb/trunk/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
 (original)
+++ 
lldb/trunk/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
 Tue Mar  5 18:45:27 2019
@@ -294,9 +294,11 @@ DynamicLoaderDarwinKernel::SearchForKern
 return LLDB_INVALID_ADDRESS;
   addr_t pc = thread->GetRegisterContext()->GetPC(LLDB_INVALID_ADDRESS);
 
+  int ptrsize = process->GetTarget().GetArchitecture().GetAddressByteSize();
+
   // The kernel is always loaded in high memory, if the top bit is zero,
   // this isn't a kernel.
-  if (process->GetTarget().GetArchitecture().GetAddressByteSize() == 8) {
+  if (ptrsize == 8) {
 if ((pc & (1ULL << 63)) == 0) {
   return LLDB_INVALID_ADDRESS;
 }
@@ -309,26 +311,26 @@ DynamicLoaderDarwinKernel::SearchForKern
   if (pc == LLDB_INVALID_ADDRESS)
 return LLDB_INVALID_ADDRESS;
 
-  // The kernel will load at at one megabyte boundary (0x10), or at that
-  // boundary plus an offset of one page (0x1000) or two, or four (0x4000),
-  // depending on the device.
-
-  // Round the current pc down to the nearest one megabyte boundary - the place
-  // where we will start searching.
-  addr_t addr = pc & ~0xf;
-
-  // Search backwards 32 megabytes, looking for the start of the kernel at each
-  // one-megabyte boundary.
-  for (int i = 0; i < 32; i++, addr -= 0x10) {
-// x86_64 kernels are at offset 0
-if (CheckForKernelImageAtAddress(addr, process).IsValid())
+  int pagesize = 0x4000;  // 16k pages on 64-bit targets
+  if (ptrsize == 4)
+pagesize = 0x1000;// 4k pages on 32-bit targets
+
+  // The kernel will be loaded on a page boundary.
+  // Round the current pc down to the nearest page boundary.
+  addr_t addr = pc & ~(pagesize - 1ULL);
+
+  // Search backwards for 32 megabytes, or first memory read error.
+  while (pc - addr < 32 * 0x10) {
+bool read_error;
+if (CheckForKernelImageAtAddress(addr, process, &read_error).IsValid())
   return addr;
-// 32-bit arm kernels are at offset 0x1000 (one 4k page)
-if (CheckForKernelImageAtAddress(addr + 0x1000, process).IsValid())
-  return addr + 0x1000;
-// 64-bit arm kernels are at offset 0x4000 (one 16k page)
-if (CheckForKernelImageAtAddress(addr + 0x4000, process).IsValid())
-  return addr + 0x4000;
+
+// Stop scanning on the first read error we encounter; we've walked
+// past this executable block of memory.
+if (read_error == true)
+  break;
+
+addr -= pagesize;
   }
 
   return LLDB_INVALID_ADDRESS;
@@ -387,13 +389,19 @@ lldb::addr_t DynamicLoaderDarwinKernel::
 //--
 
 bool
-DynamicLoaderDarwinKernel::ReadMachHeader(addr_t addr, Process *process, 
llvm::MachO::mach_header &header) {
-  Status read_error;
+DynamicLoaderDarwinKernel::ReadMachHeader(addr_t addr, Process *process, 
llvm::MachO::mach_header &header,
+  bool *read_error) {
+  Status error;
+  if (read_error)
+*read_error = false;
 
   // Read the mach header and see whether it looks like a kernel
-  if (process->DoReadMemory (addr, &header, sizeof(header), read_error) !=
-  sizeof(header))
+  if (process->DoReadMemory (addr, &header, sizeof(header), error) !=
+  sizeo