[Lldb-commits] [PATCH] D50384: Move Predicate.h from Host to Utility

[Pavel Labath via Phabricator via lldb-commits]

labath updated this revision to Diff 159649.
labath added a comment.

Updating the module map too (thanks).


https://reviews.llvm.org/D50384

Files:
  include/lldb/Core/Event.h
  include/lldb/Core/IOHandler.h
  include/lldb/Host/Editline.h
  include/lldb/Host/Predicate.h
  include/lldb/Host/Socket.h
  include/lldb/Host/posix/ConnectionFileDescriptorPosix.h
  include/lldb/Utility/Predicate.h
  include/lldb/module.modulemap
  source/Core/IOHandler.cpp
  source/Host/common/Host.cpp
  source/Plugins/Process/MacOSX-Kernel/CommunicationKDP.h
  source/Plugins/Process/Windows/Common/DebuggerThread.cpp
  source/Plugins/Process/Windows/Common/DebuggerThread.h
  source/Plugins/Process/gdb-remote/GDBRemoteCommunication.h
  unittests/Core/BroadcasterTest.cpp
  unittests/Host/CMakeLists.txt
  unittests/Host/PredicateTest.cpp
  unittests/Utility/CMakeLists.txt
  unittests/Utility/PredicateTest.cpp

Index: unittests/Utility/PredicateTest.cpp
===
--- unittests/Utility/PredicateTest.cpp
+++ unittests/Utility/PredicateTest.cpp
@@ -7,7 +7,7 @@
 //
 //===--===//
 
-#include "lldb/Host/Predicate.h"
+#include "lldb/Utility/Predicate.h"
 #include "gtest/gtest.h"
 #include 
 
Index: unittests/Utility/CMakeLists.txt
===
--- unittests/Utility/CMakeLists.txt
+++ unittests/Utility/CMakeLists.txt
@@ -12,6 +12,7 @@
   JSONTest.cpp
   LogTest.cpp
   NameMatchesTest.cpp
+  PredicateTest.cpp
   RegisterValueTest.cpp
   ScalarTest.cpp
   StateTest.cpp
Index: unittests/Host/CMakeLists.txt
===
--- unittests/Host/CMakeLists.txt
+++ unittests/Host/CMakeLists.txt
@@ -3,7 +3,6 @@
   HostInfoTest.cpp
   HostTest.cpp
   MainLoopTest.cpp
-  PredicateTest.cpp
   SocketAddressTest.cpp
   SocketTest.cpp
   SymbolsTest.cpp
Index: unittests/Core/BroadcasterTest.cpp
===
--- unittests/Core/BroadcasterTest.cpp
+++ unittests/Core/BroadcasterTest.cpp
@@ -12,7 +12,7 @@
 #include "lldb/Core/Broadcaster.h"
 #include "lldb/Core/Event.h"
 #include "lldb/Core/Listener.h"
-#include "lldb/Host/Predicate.h"
+#include "lldb/Utility/Predicate.h"
 
 #include 
 
Index: source/Plugins/Process/gdb-remote/GDBRemoteCommunication.h
===
--- source/Plugins/Process/gdb-remote/GDBRemoteCommunication.h
+++ source/Plugins/Process/gdb-remote/GDBRemoteCommunication.h
@@ -23,8 +23,8 @@
 #include "lldb/Core/Communication.h"
 #include "lldb/Core/Listener.h"
 #include "lldb/Host/HostThread.h"
-#include "lldb/Host/Predicate.h"
 #include "lldb/Utility/Args.h"
+#include "lldb/Utility/Predicate.h"
 #include "lldb/lldb-public.h"
 
 #include "lldb/Utility/StringExtractorGDBRemote.h"
Index: source/Plugins/Process/Windows/Common/DebuggerThread.h
===
--- source/Plugins/Process/Windows/Common/DebuggerThread.h
+++ source/Plugins/Process/Windows/Common/DebuggerThread.h
@@ -16,8 +16,8 @@
 #include "ForwardDecl.h"
 #include "lldb/Host/HostProcess.h"
 #include "lldb/Host/HostThread.h"
-#include "lldb/Host/Predicate.h"
 #include "lldb/Host/windows/windows.h"
+#include "lldb/Utility/Predicate.h"
 
 namespace lldb_private {
 
Index: source/Plugins/Process/Windows/Common/DebuggerThread.cpp
===
--- source/Plugins/Process/Windows/Common/DebuggerThread.cpp
+++ source/Plugins/Process/Windows/Common/DebuggerThread.cpp
@@ -12,15 +12,15 @@
 #include "IDebugDelegate.h"
 
 #include "lldb/Core/ModuleSpec.h"
-#include "lldb/Host/Predicate.h"
 #include "lldb/Host/ThreadLauncher.h"
 #include "lldb/Host/windows/HostProcessWindows.h"
 #include "lldb/Host/windows/HostThreadWindows.h"
 #include "lldb/Host/windows/ProcessLauncherWindows.h"
 #include "lldb/Target/Process.h"
 #include "lldb/Target/ProcessLaunchInfo.h"
 #include "lldb/Utility/FileSpec.h"
 #include "lldb/Utility/Log.h"
+#include "lldb/Utility/Predicate.h"
 #include "lldb/Utility/Status.h"
 
 #include "Plugins/Process/Windows/Common/ProcessWindowsLog.h"
Index: source/Plugins/Process/MacOSX-Kernel/CommunicationKDP.h
===
--- source/Plugins/Process/MacOSX-Kernel/CommunicationKDP.h
+++ source/Plugins/Process/MacOSX-Kernel/CommunicationKDP.h
@@ -21,7 +21,7 @@
 #include "lldb/Core/Communication.h"
 #include "lldb/Core/Listener.h"
 #include "lldb/Core/StreamBuffer.h"
-#include "lldb/Host/Predicate.h"
+#include "lldb/Utility/Predicate.h"
 #include "lldb/lldb-private.h"
 
 class CommunicationKDP : public lldb_private::Communication {
Index: source/Host/common/Host.cpp
===
--- source/Host/common/Host.cpp
+++ source/Host/common/Host.cpp
@@ -

[Lldb-commits] [PATCH] D50071: Use rich mangling information in Symtab::InitNameIndexes()

[Stefan Gränitz via Phabricator via lldb-commits]

sgraenitz updated this revision to Diff 159654.
sgraenitz added a comment.

Add unit tests for RichManglingContext


https://reviews.llvm.org/D50071

Files:
  include/lldb/Core/Mangled.h
  include/lldb/Core/RichManglingContext.h
  include/lldb/Symbol/Symtab.h
  include/lldb/lldb-forward.h
  lldb.xcodeproj/project.pbxproj
  source/Core/CMakeLists.txt
  source/Core/Mangled.cpp
  source/Core/RichManglingContext.cpp
  source/Symbol/Symtab.cpp
  unittests/Core/RichManglingContextTest.cpp

Index: unittests/Core/RichManglingContextTest.cpp
===
--- /dev/null
+++ unittests/Core/RichManglingContextTest.cpp
@@ -0,0 +1,114 @@
+//===-- RichManglingContextTest.cpp -*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "lldb/Core/RichManglingContext.h"
+
+#include "lldb/Utility/ConstString.h"
+
+#include "gtest/gtest.h"
+
+using namespace lldb;
+using namespace lldb_private;
+
+TEST(RichManglingContextTest, Basic) {
+  RichManglingContext RMC;
+  ConstString mangled("_ZN3foo3barEv");
+  EXPECT_TRUE(RMC.FromItaniumName(mangled));
+
+  EXPECT_TRUE(RMC.IsFunction());
+  EXPECT_FALSE(RMC.IsCtorOrDtor());
+
+  RMC.ParseFunctionDeclContextName();
+  EXPECT_EQ("foo", RMC.GetBufferRef());
+
+  RMC.ParseFunctionBaseName();
+  EXPECT_EQ("bar", RMC.GetBufferRef());
+
+  RMC.ParseFullName();
+  EXPECT_EQ("foo::bar()", RMC.GetBufferRef());
+}
+
+TEST(RichManglingContextTest, FromCxxMethodName) {
+  RichManglingContext ItaniumRMC;
+  ConstString mangled("_ZN3foo3barEv");
+  EXPECT_TRUE(ItaniumRMC.FromItaniumName(mangled));
+
+  RichManglingContext CxxMethodRMC;
+  ConstString demangled("foo::bar()");
+  EXPECT_TRUE(CxxMethodRMC.FromCxxMethodName(demangled));
+
+  EXPECT_TRUE(ItaniumRMC.IsFunction() == CxxMethodRMC.IsFunction());
+  EXPECT_TRUE(ItaniumRMC.IsCtorOrDtor() == CxxMethodRMC.IsCtorOrDtor());
+
+  ItaniumRMC.ParseFunctionDeclContextName();
+  CxxMethodRMC.ParseFunctionDeclContextName();
+  EXPECT_TRUE(ItaniumRMC.GetBufferRef() == CxxMethodRMC.GetBufferRef());
+
+  ItaniumRMC.ParseFunctionBaseName();
+  CxxMethodRMC.ParseFunctionBaseName();
+  EXPECT_TRUE(ItaniumRMC.GetBufferRef() == CxxMethodRMC.GetBufferRef());
+
+  ItaniumRMC.ParseFullName();
+  CxxMethodRMC.ParseFullName();
+  EXPECT_TRUE(ItaniumRMC.GetBufferRef() == CxxMethodRMC.GetBufferRef());
+}
+
+TEST(RichManglingContextTest, SwitchProvider) {
+  RichManglingContext RMC;
+  ConstString mangled("_ZN3foo3barEv");
+  ConstString demangled("foo::bar()");
+
+  EXPECT_TRUE(RMC.FromItaniumName(mangled));
+  RMC.ParseFullName();
+  EXPECT_STREQ("foo::bar()", RMC.GetBuffer().GetCString());
+
+  EXPECT_TRUE(RMC.FromCxxMethodName(demangled));
+  RMC.ParseFullName();
+  EXPECT_STREQ("foo::bar()", RMC.GetBuffer().GetCString());
+
+  EXPECT_TRUE(RMC.FromItaniumName(mangled));
+  RMC.ParseFullName();
+  EXPECT_STREQ("foo::bar()", RMC.GetBuffer().GetCString());
+}
+
+TEST(RichManglingContextTest, Realloc) {
+  // The demangled name should fit into the default buffer.
+  const char *short_mangled = "_ZN3foo3barEv";
+
+  // The demangled name for this will certainly not fit into the default buffer.
+  const char *long_mangled =
+  "_ZNK3shk6detail17CallbackPublisherIZNS_5ThrowERKNSt15__exception_"
+  "ptr13exception_ptrEEUlOT_E_E9SubscribeINS0_9ConcatMapINS0_"
+  "18CallbackSubscriberIZNS_6GetAllIiNS1_IZZNS_9ConcatMapIZNS_6ConcatIJNS1_"
+  "IZZNS_3MapIZZNS_7IfEmptyIS9_EEDaS7_ENKUlS6_E_clINS1_IZZNS_4TakeIiEESI_"
+  "S7_ENKUlS6_E_clINS1_IZZNS_6FilterIZNS_9ElementAtEmEUlS7_E_EESI_S7_"
+  "ENKUlS6_E_clINS1_IZZNSL_ImEESI_S7_ENKUlS6_E_clINS1_IZNS_4FromINS0_"
+  "22InfiniteRangeContainerIiSI_S7_EUlS7_E_SI_S6_EUlS7_E_SI_S6_"
+  "EUlS7_E_SI_S6_EUlS7_E_SI_S6_EUlS7_E_EESI_S7_ENKUlS6_E_clIS14_"
+  "EESI_S6_EUlS7_E_EERNS1_IZZNSH_IS9_EESI_S7_ENKSK_IS14_EESI_S6_EUlS7_E0_"
+  "ESI_DpOT_EUlS7_E_EESI_S7_ENKUlS6_E_clINS1_IZNS_5StartIJZNS_"
+  "4JustIJS19_S1C_EEESI_S1F_EUlvE_ZNS1K_IJS19_S1C_EEESI_S1F_EUlvE0_EEESI_"
+  "S1F_EUlS7_E_SI_S6_EUlS7_E_St6vectorIS6_SaIS6_EERKT0_NS_"
+  "12ElementCountEbEUlS7_E_ZNSD_IiS1Q_EES1T_S1W_S1X_bEUlOS3_E_ZNSD_IiS1Q_"
+  "EES1T_S1W_S1X_bEUlvE_EES1G_S1O_E25ConcatMapValuesSubscriberEEEDaS7_";
+
+  RichManglingContext RMC;
+
+  // Demangle the short one and remember the buffer address.
+  EXPECT_TRUE(RMC.FromItaniumName(ConstString(short_mangled)));
+  RMC.ParseFullName();
+  const char *short_demangled_ptr = RMC.GetBufferRef().data();
+
+  // Demangle the long one and make sure the buffer address changed.
+  EXPECT_TRUE(RMC.FromItaniumName(ConstString(long_mangled)));
+  RMC.ParseFullName();
+  const char *long_demangled_ptr = RMC.GetBufferRef().data();
+
+  EXP

[Lldb-commits] [PATCH] D50071: Use rich mangling information in Symtab::InitNameIndexes()

[Stefan Gränitz via Phabricator via lldb-commits]

sgraenitz added inline comments.



Comment at: source/Core/RichManglingContext.cpp:133
+  case PluginCxxLanguage:
+m_cxx_method_str = ConstString(
+
get(m_cxx_method_parser)->GetBasename());

labath wrote:
> I thought we were going to get rid of this ConstString? The C++ plugin is 
> able to provide the same (in fact, even stronger) lifetime guarantees as the 
> IPD, so we could just have a single method that always returns a StringRef. 
> (If you really want to, you can also have a ConstString-returning helper 
> function, but it could be implemented the same way as it is now for IPD, so 
> that both versions have the same runtime complexity.
> 
> I'd suggest having just a m_buffer StringRef object, which you set both here 
> and in processIPDStrResult. Then `GetBufferRef()` can just return that object 
> without any branching involved.
Yes, I can change the ConstString thing here.

> I'd suggest having just a m_buffer StringRef object
You mean a single buffer for both, IPD and C++ method parser plugin? Actually I 
don't like to mix that. In case of IPD the buffer is owned by the context. 
Otherwise it's owned by the C++ method parser plugin. I could manage that in 
`FromItaniumName` and `FromCxxMethodName`, but it will make everything more 
complicated. Top prio for me is to avoid reallocation of the relatively big 
initial `m_IPD_buf` and I think the cleanest way to do this is the RAII-style 
that's used already.


https://reviews.llvm.org/D50071



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

[Lldb-commits] [PATCH] D50365: Add a new tool named "lldb-vscode" that implements the Visual Studio Code Debug Adaptor Protocol

[Pavel Labath via Phabricator via lldb-commits]

labath edited reviewers, added: zturner, davide; removed: labath.
labath added a comment.

I am not sure I'll have the resources to see this review through, so I'd prefer 
to leave this to someone else.

The thoughts I have had so far are:

- the patch is very big and probably runs afoul of the "you shall develop 
incrementally" section in the LLVM developer policy. At least the JSON parts 
should be split off into a separate patch and tested independently.
- however, the choice of the JSON library is also an open question. We 
currently have at least three options to choose from:
  - llvm/Support/JSON.h
  - lldb/Utility/JSON.h
  - debugserver/source/JSON.h

Of these, the third one is the one I'd least expect to be used here.

- Since this is essentially starting a new-subproject, I think it's in place to 
discuss various conventions. E.g., right now, this seems to use a mixture of 
UpperCamel and snake_case, and so isn't very consistent with neither llvm nor 
lldb naming conventions.




Comment at: 
packages/Python/lldbsuite/test/tools/lldb-vscode/attach/TestVSCode_attach.py:47
+
+@no_debug_info_test
+def test_by_pid(self):

You might want to set `NO_DEBUG_INFO_TESTCASE = True` in the base 
`VSCodeTestCaseBase` to avoid these. I guess none of these tests should be 
debug-info dependent, right?



Comment at: tools/lldb-vscode/lldb-vscode.cpp:1688
+
+void __attribute__((format(printf, 2, 3)))
+send_formatted_output(OutputType o, const char *format, ...) {

gcc-specific attribute


https://reviews.llvm.org/D50365



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

[Lldb-commits] [PATCH] D50071: Use rich mangling information in Symtab::InitNameIndexes()

[Pavel Labath via Phabricator via lldb-commits]

labath added inline comments.



Comment at: source/Core/RichManglingContext.cpp:133
+  case PluginCxxLanguage:
+m_cxx_method_str = ConstString(
+
get(m_cxx_method_parser)->GetBasename());

sgraenitz wrote:
> labath wrote:
> > I thought we were going to get rid of this ConstString? The C++ plugin is 
> > able to provide the same (in fact, even stronger) lifetime guarantees as 
> > the IPD, so we could just have a single method that always returns a 
> > StringRef. (If you really want to, you can also have a 
> > ConstString-returning helper function, but it could be implemented the same 
> > way as it is now for IPD, so that both versions have the same runtime 
> > complexity.
> > 
> > I'd suggest having just a m_buffer StringRef object, which you set both 
> > here and in processIPDStrResult. Then `GetBufferRef()` can just return that 
> > object without any branching involved.
> Yes, I can change the ConstString thing here.
> 
> > I'd suggest having just a m_buffer StringRef object
> You mean a single buffer for both, IPD and C++ method parser plugin? Actually 
> I don't like to mix that. In case of IPD the buffer is owned by the context. 
> Otherwise it's owned by the C++ method parser plugin. I could manage that in 
> `FromItaniumName` and `FromCxxMethodName`, but it will make everything more 
> complicated. Top prio for me is to avoid reallocation of the relatively big 
> initial `m_IPD_buf` and I think the cleanest way to do this is the RAII-style 
> that's used already.
Well, kind of. I guess I shouldn't have said /just/ an m_buffer object. For the 
itanium case, this buffer would be /in addition/ to the existing m_PID_XXX 
members.

The operating invariant would be that m_buffer is a non-owning reference to the 
string which was set by the last `ParseXXX` call. So, for the CPlusPlus case it 
means you would here to something like `m_buffer = 
get(m_cxx_method_parser)->GetBasename();`. And 
in the itanium case, you would set `m_buffer = StringRef(m_IPD_buf, 
m_IPD_str_size)`, after you finish all other work.

I don't think that should affect any of the work you do already, it should just 
make the GetBufferRef function simpler (and faster).


https://reviews.llvm.org/D50071



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

[Lldb-commits] [PATCH] D50071: Use rich mangling information in Symtab::InitNameIndexes()

[Stefan Gränitz via Phabricator via lldb-commits]

sgraenitz updated this revision to Diff 159678.
sgraenitz added a comment.

Polishing


https://reviews.llvm.org/D50071

Files:
  include/lldb/Core/Mangled.h
  include/lldb/Core/RichManglingContext.h
  include/lldb/Symbol/Symtab.h
  include/lldb/lldb-forward.h
  lldb.xcodeproj/project.pbxproj
  source/Core/CMakeLists.txt
  source/Core/Mangled.cpp
  source/Core/RichManglingContext.cpp
  source/Symbol/Symtab.cpp
  unittests/Core/CMakeLists.txt
  unittests/Core/RichManglingContextTest.cpp

Index: unittests/Core/RichManglingContextTest.cpp
===
--- /dev/null
+++ unittests/Core/RichManglingContextTest.cpp
@@ -0,0 +1,114 @@
+//===-- RichManglingContextTest.cpp -*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "lldb/Core/RichManglingContext.h"
+
+#include "lldb/Utility/ConstString.h"
+
+#include "gtest/gtest.h"
+
+using namespace lldb;
+using namespace lldb_private;
+
+TEST(RichManglingContextTest, Basic) {
+  RichManglingContext RMC;
+  ConstString mangled("_ZN3foo3barEv");
+  EXPECT_TRUE(RMC.FromItaniumName(mangled));
+
+  EXPECT_TRUE(RMC.IsFunction());
+  EXPECT_FALSE(RMC.IsCtorOrDtor());
+
+  RMC.ParseFunctionDeclContextName();
+  EXPECT_EQ("foo", RMC.GetBufferRef());
+
+  RMC.ParseFunctionBaseName();
+  EXPECT_EQ("bar", RMC.GetBufferRef());
+
+  RMC.ParseFullName();
+  EXPECT_EQ("foo::bar()", RMC.GetBufferRef());
+}
+
+TEST(RichManglingContextTest, FromCxxMethodName) {
+  RichManglingContext ItaniumRMC;
+  ConstString mangled("_ZN3foo3barEv");
+  EXPECT_TRUE(ItaniumRMC.FromItaniumName(mangled));
+
+  RichManglingContext CxxMethodRMC;
+  ConstString demangled("foo::bar()");
+  EXPECT_TRUE(CxxMethodRMC.FromCxxMethodName(demangled));
+
+  EXPECT_TRUE(ItaniumRMC.IsFunction() == CxxMethodRMC.IsFunction());
+  EXPECT_TRUE(ItaniumRMC.IsCtorOrDtor() == CxxMethodRMC.IsCtorOrDtor());
+
+  ItaniumRMC.ParseFunctionDeclContextName();
+  CxxMethodRMC.ParseFunctionDeclContextName();
+  EXPECT_TRUE(ItaniumRMC.GetBufferRef() == CxxMethodRMC.GetBufferRef());
+
+  ItaniumRMC.ParseFunctionBaseName();
+  CxxMethodRMC.ParseFunctionBaseName();
+  EXPECT_TRUE(ItaniumRMC.GetBufferRef() == CxxMethodRMC.GetBufferRef());
+
+  ItaniumRMC.ParseFullName();
+  CxxMethodRMC.ParseFullName();
+  EXPECT_TRUE(ItaniumRMC.GetBufferRef() == CxxMethodRMC.GetBufferRef());
+}
+
+TEST(RichManglingContextTest, SwitchProvider) {
+  RichManglingContext RMC;
+  llvm::StringRef mangled = "_ZN3foo3barEv";
+  llvm::StringRef demangled = "foo::bar()";
+
+  EXPECT_TRUE(RMC.FromItaniumName(ConstString(mangled)));
+  RMC.ParseFullName();
+  EXPECT_EQ("foo::bar()", RMC.GetBufferRef());
+
+  EXPECT_TRUE(RMC.FromCxxMethodName(ConstString(demangled)));
+  RMC.ParseFullName();
+  EXPECT_EQ("foo::bar()", RMC.GetBufferRef());
+
+  EXPECT_TRUE(RMC.FromItaniumName(ConstString(mangled)));
+  RMC.ParseFullName();
+  EXPECT_EQ("foo::bar()", RMC.GetBufferRef());
+}
+
+TEST(RichManglingContextTest, IPDRealloc) {
+  // The demangled name should fit into the Itanium default buffer.
+  const char *short_mangled = "_ZN3foo3barEv";
+
+  // The demangled name for this will certainly not fit into the default buffer.
+  const char *long_mangled =
+  "_ZNK3shk6detail17CallbackPublisherIZNS_5ThrowERKNSt15__exception_"
+  "ptr13exception_ptrEEUlOT_E_E9SubscribeINS0_9ConcatMapINS0_"
+  "18CallbackSubscriberIZNS_6GetAllIiNS1_IZZNS_9ConcatMapIZNS_6ConcatIJNS1_"
+  "IZZNS_3MapIZZNS_7IfEmptyIS9_EEDaS7_ENKUlS6_E_clINS1_IZZNS_4TakeIiEESI_"
+  "S7_ENKUlS6_E_clINS1_IZZNS_6FilterIZNS_9ElementAtEmEUlS7_E_EESI_S7_"
+  "ENKUlS6_E_clINS1_IZZNSL_ImEESI_S7_ENKUlS6_E_clINS1_IZNS_4FromINS0_"
+  "22InfiniteRangeContainerIiSI_S7_EUlS7_E_SI_S6_EUlS7_E_SI_S6_"
+  "EUlS7_E_SI_S6_EUlS7_E_SI_S6_EUlS7_E_EESI_S7_ENKUlS6_E_clIS14_"
+  "EESI_S6_EUlS7_E_EERNS1_IZZNSH_IS9_EESI_S7_ENKSK_IS14_EESI_S6_EUlS7_E0_"
+  "ESI_DpOT_EUlS7_E_EESI_S7_ENKUlS6_E_clINS1_IZNS_5StartIJZNS_"
+  "4JustIJS19_S1C_EEESI_S1F_EUlvE_ZNS1K_IJS19_S1C_EEESI_S1F_EUlvE0_EEESI_"
+  "S1F_EUlS7_E_SI_S6_EUlS7_E_St6vectorIS6_SaIS6_EERKT0_NS_"
+  "12ElementCountEbEUlS7_E_ZNSD_IiS1Q_EES1T_S1W_S1X_bEUlOS3_E_ZNSD_IiS1Q_"
+  "EES1T_S1W_S1X_bEUlvE_EES1G_S1O_E25ConcatMapValuesSubscriberEEEDaS7_";
+
+  RichManglingContext RMC;
+
+  // Demangle the short one and remember the buffer address.
+  EXPECT_TRUE(RMC.FromItaniumName(ConstString(short_mangled)));
+  RMC.ParseFullName();
+  const char *short_demangled_ptr = RMC.GetBufferRef().data();
+
+  // Demangle the long one and make sure the buffer address changed.
+  EXPECT_TRUE(RMC.FromItaniumName(ConstString(long_mangled)));
+  RMC.ParseFullName();
+  const char *long_demangled_ptr = RMC.GetBuff

[Lldb-commits] [PATCH] D50071: Use rich mangling information in Symtab::InitNameIndexes()

[Stefan Gränitz via Phabricator via lldb-commits]

sgraenitz marked an inline comment as done.
sgraenitz added a comment.

Tests, polishing and renaming (as discussed with @jingham).

If you have more comments on this, please let me know.
Otherwise I'd be fine with keeping it like this.


https://reviews.llvm.org/D50071



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

[Lldb-commits] [PATCH] D50071: Use rich mangling information in Symtab::InitNameIndexes()

[Pavel Labath via Phabricator via lldb-commits]

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

I think this looks great. I am very happy with the final result. Thank you for 
your patience, and thanks again for taking on this task.


https://reviews.llvm.org/D50071



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

[Lldb-commits] [PATCH] D50365: Add a new tool named "lldb-vscode" that implements the Visual Studio Code Debug Adaptor Protocol

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

To end things on a positive note: I think the test coverage is pretty good (I'm 
sure somebody will suggest switching to lit), and I think a VS code plugin 
would be a great addition to lldb.


https://reviews.llvm.org/D50365



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

Re: [Lldb-commits] [PATCH] D50365: Add a new tool named "lldb-vscode" that implements the Visual Studio Code Debug Adaptor Protocol

[Zachary Turner via lldb-commits]

How does this differ from VS Code's builtin LLDB MI support?

On Wed, Aug 8, 2018 at 8:15 AM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:

> labath added a comment.
>
> To end things on a positive note: I think the test coverage is pretty good
> (I'm sure somebody will suggest switching to lit), and I think a VS code
> plugin would be a great addition to lldb.
>
>
> https://reviews.llvm.org/D50365
>
>
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D50365: Add a new tool named "lldb-vscode" that implements the Visual Studio Code Debug Adaptor Protocol

[Zachary Turner via Phabricator via lldb-commits]

zturner added a comment.

How does this differ from VS Code's builtin LLDB MI support?


https://reviews.llvm.org/D50365



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

Re: [Lldb-commits] [PATCH] D50365: Add a new tool named "lldb-vscode" that implements the Visual Studio Code Debug Adaptor Protocol

[Zachary Turner via lldb-commits]

To elaborate, if you install the C/C++ plugin, and you go to Debug ->
Configurations, and you go down to the MICmdMode property, it is by default
set to "gdb".  But you can change this to "lldb" and it works out of the
box.

On Wed, Aug 8, 2018 at 8:30 AM Zachary Turner  wrote:

> How does this differ from VS Code's builtin LLDB MI support?
>
> On Wed, Aug 8, 2018 at 8:15 AM Pavel Labath via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
>> labath added a comment.
>>
>> To end things on a positive note: I think the test coverage is pretty
>> good (I'm sure somebody will suggest switching to lit), and I think a VS
>> code plugin would be a great addition to lldb.
>>
>>
>> https://reviews.llvm.org/D50365
>>
>>
>>
>>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D50365: Add a new tool named "lldb-vscode" that implements the Visual Studio Code Debug Adaptor Protocol

[Zachary Turner via Phabricator via lldb-commits]

zturner added a comment.

To elaborate, if you install the C/C++ plugin, and you go to Debug ->
Configurations, and you go down to the MICmdMode property, it is by default
set to "gdb".  But you can change this to "lldb" and it works out of the
box.


https://reviews.llvm.org/D50365



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

[Lldb-commits] [PATCH] D50384: Move Predicate.h from Host to Utility

[Zachary Turner via Phabricator via lldb-commits]

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

lgtm, although Predicate is simple enough that I wonder if one day we should 
try to just delete it entirely.


https://reviews.llvm.org/D50384



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

Re: [Lldb-commits] [PATCH] D50365: Add a new tool named "lldb-vscode" that implements the Visual Studio Code Debug Adaptor Protocol

[Greg Clayton via lldb-commits]

It is a different protocol. The LLDB MI plugin didn't work very well as was 
quite flaky when I tested it a while back. Then I grabbed the CodeLLDB plugin 
by Vadim Chugunov and it worked very well. When I looked more closely at this 
plugin, it was using a javascript/typescript plug-in to launch a LLDB instance 
and then ran a python script that received all of the javascript packets from 
the javascript/typescript based plug-in and ran the debug session. It worked 
very well and was rock solid stable. So I then created this plug-in for Nuclide 
for use at Facebook as they switched all of the debugging plug-in over to use 
the VSCode debug adaptor protocols. It works event better than the CodeLLDB 
plugin with Visual Studio Code and it also doesn't stop you from using the 
python interpreter. The issue I had with the CodeLLDB is that is uses the 
python interpreter to run the debug session thus it isn't available to you as a 
LLDB user.

So long story short: our IDE at Facebook uses the VSCode protocol, MI is clunky 
and doesn't work that well and was flaky, so this tool was created. This also 
provides a really nice way to do remote debugging where the lldb-vscode is run 
remotely on other systems. This removes the need for copying files from a 
remote host up onto the system that is doing the debugging.

Greg

> On Aug 8, 2018, at 8:30 AM, Zachary Turner  wrote:
> 
> How does this differ from VS Code's builtin LLDB MI support?
> 
> On Wed, Aug 8, 2018 at 8:15 AM Pavel Labath via Phabricator 
> mailto:revi...@reviews.llvm.org>> wrote:
> labath added a comment.
> 
> To end things on a positive note: I think the test coverage is pretty good 
> (I'm sure somebody will suggest switching to lit), and I think a VS code 
> plugin would be a great addition to lldb.
> 
> 
> https://reviews.llvm.org/D50365 
> 
> 
> 

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

[Lldb-commits] [PATCH] D50365: Add a new tool named "lldb-vscode" that implements the Visual Studio Code Debug Adaptor Protocol

[Greg Clayton via Phabricator via lldb-commits]

clayborg added a comment.

In https://reviews.llvm.org/D50365#1192447, @zturner wrote:

> To elaborate, if you install the C/C++ plugin, and you go to Debug ->
>  Configurations, and you go down to the MICmdMode property, it is by default
>  set to "gdb".  But you can change this to "lldb" and it works out of the
>  box.


It is a different protocol. The LLDB MI plugin didn't work very well as was 
quite flaky when I tested it a while back. Then I grabbed the CodeLLDB plugin 
by Vadim Chugunov and it worked very well. When I looked more closely at this 
plugin, it was using a javascript/typescript plug-in to launch a LLDB instance 
and then ran a python script that received all of the javascript packets from 
the javascript/typescript based plug-in and ran the debug session using the 
python interpreter. It worked very well and was rock solid stable. So I then 
created this plug-in for Nuclide for use at Facebook as they switched all of 
the debugging plug-in over to use the VSCode debug adaptor protocols. It works 
event better than the CodeLLDB plugin with Visual Studio Code and it also 
doesn't stop you from using the python interpreter. The issue I had with the 
CodeLLDB is that is uses the python interpreter to run the debug session thus 
it isn't available to you as a LLDB user.

So long story short: our IDE at Facebook uses the VSCode protocol, MI is clunky 
and doesn't work that well and was flaky, so this tool was created. This also 
provides a really nice way to do remote debugging where the lldb-vscode is run 
remotely on other systems. This removes the need for copying files from a 
remote host up onto the system that is doing the debugging. So we use this at 
Facebook and it also provides the best way to use LLDB to debug using Visual 
Studio Code or Nuclide.


https://reviews.llvm.org/D50365



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

Re: [Lldb-commits] [PATCH] D50365: Add a new tool named "lldb-vscode" that implements the Visual Studio Code Debug Adaptor Protocol

[Zachary Turner via lldb-commits]

Ok sounds good then, mostly just wanted to make sure you weren't
re-inventing something that already existed :)  Do you plan to publish this
on the VSCode marketplace?

On Wed, Aug 8, 2018 at 8:38 AM Greg Clayton  wrote:

> It is a different protocol. The LLDB MI plugin didn't work very well as
> was quite flaky when I tested it a while back. Then I grabbed the CodeLLDB
> plugin by Vadim Chugunov and it worked very well. When I looked more
> closely at this plugin, it was using a javascript/typescript plug-in to
> launch a LLDB instance and then ran a python script that received all of
> the javascript packets from the javascript/typescript based plug-in and ran
> the debug session. It worked very well and was rock solid stable. So I then
> created this plug-in for Nuclide for use at Facebook as they switched all
> of the debugging plug-in over to use the VSCode debug adaptor protocols. It
> works event better than the CodeLLDB plugin with Visual Studio Code and it
> also doesn't stop you from using the python interpreter. The issue I had
> with the CodeLLDB is that is uses the python interpreter to run the debug
> session thus it isn't available to you as a LLDB user.
>
> So long story short: our IDE at Facebook uses the VSCode protocol, MI is
> clunky and doesn't work that well and was flaky, so this tool was created.
> This also provides a really nice way to do remote debugging where the
> lldb-vscode is run remotely on other systems. This removes the need for
> copying files from a remote host up onto the system that is doing the
> debugging.
>
> Greg
>
> On Aug 8, 2018, at 8:30 AM, Zachary Turner  wrote:
>
> How does this differ from VS Code's builtin LLDB MI support?
>
> On Wed, Aug 8, 2018 at 8:15 AM Pavel Labath via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
>> labath added a comment.
>>
>> To end things on a positive note: I think the test coverage is pretty
>> good (I'm sure somebody will suggest switching to lit), and I think a VS
>> code plugin would be a great addition to lldb.
>>
>>
>> https://reviews.llvm.org/D50365
>>
>>
>>
>>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D50365: Add a new tool named "lldb-vscode" that implements the Visual Studio Code Debug Adaptor Protocol

[Greg Clayton via lldb-commits]

> On Aug 8, 2018, at 8:40 AM, Zachary Turner  wrote:
> 
> Ok sounds good then, mostly just wanted to make sure you weren't re-inventing 
> something that already existed :)  Do you plan to publish this on the VSCode 
> marketplace?

I would like to. Not sure how this works with native binaries as most VSCode 
plug-ins are typescript that can be recompiled on the fly on each system. If 
they do allow native plugins, then yes.

> 
> On Wed, Aug 8, 2018 at 8:38 AM Greg Clayton  > wrote:
> It is a different protocol. The LLDB MI plugin didn't work very well as was 
> quite flaky when I tested it a while back. Then I grabbed the CodeLLDB plugin 
> by Vadim Chugunov and it worked very well. When I looked more closely at this 
> plugin, it was using a javascript/typescript plug-in to launch a LLDB 
> instance and then ran a python script that received all of the javascript 
> packets from the javascript/typescript based plug-in and ran the debug 
> session. It worked very well and was rock solid stable. So I then created 
> this plug-in for Nuclide for use at Facebook as they switched all of the 
> debugging plug-in over to use the VSCode debug adaptor protocols. It works 
> event better than the CodeLLDB plugin with Visual Studio Code and it also 
> doesn't stop you from using the python interpreter. The issue I had with the 
> CodeLLDB is that is uses the python interpreter to run the debug session thus 
> it isn't available to you as a LLDB user.
> 
> So long story short: our IDE at Facebook uses the VSCode protocol, MI is 
> clunky and doesn't work that well and was flaky, so this tool was created. 
> This also provides a really nice way to do remote debugging where the 
> lldb-vscode is run remotely on other systems. This removes the need for 
> copying files from a remote host up onto the system that is doing the 
> debugging.
> 
> Greg
> 
>> On Aug 8, 2018, at 8:30 AM, Zachary Turner > > wrote:
>> 
>> How does this differ from VS Code's builtin LLDB MI support?
>> 
>> On Wed, Aug 8, 2018 at 8:15 AM Pavel Labath via Phabricator 
>> mailto:revi...@reviews.llvm.org>> wrote:
>> labath added a comment.
>> 
>> To end things on a positive note: I think the test coverage is pretty good 
>> (I'm sure somebody will suggest switching to lit), and I think a VS code 
>> plugin would be a great addition to lldb.
>> 
>> 
>> https://reviews.llvm.org/D50365 
>> 
>> 
>> 
> 

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

[Lldb-commits] [PATCH] D50365: Add a new tool named "lldb-vscode" that implements the Visual Studio Code Debug Adaptor Protocol

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere added a comment.

This looks really cool :-)

I started doing a superficial pass but I have a hard time following what 
everything is doing. I think it could really help if you added more 
structure/abstraction. Can you also run clang-format over the new files?




Comment at: tools/lldb-vscode/lldb-vscode.cpp:65
+
+#define VARREF_LOCALS (int64_t)1
+#define VARREF_GLOBALS(int64_t)2

Can we replace these with static consexprs?



Comment at: tools/lldb-vscode/lldb-vscode.cpp:93
+
+uint64_t string_to_unsigned(const char *s, int base, uint64_t fail_value) {
+  if (s && s[0]) {

I think you could use llvm's `to_integer` from StringExtras.h for this. 



Comment at: tools/lldb-vscode/lldb-vscode.cpp:117
+bool
+thread_has_stop_reason(lldb::SBThread &thread) {
+  switch (thread.GetStopReason()) {

Should this maybe become a member of (SB)Thread?



Comment at: tools/lldb-vscode/lldb-vscode.cpp:136
+
+enum OutputType {
+  Console,

I very much prefer enum classes to prevent collisions. It's probably not that 
important here but it also doesn't harm to have the values qualified with the 
enum name. Same for the other enums in this file. 



Comment at: tools/lldb-vscode/lldb-vscode.cpp:253
+
+struct BreakpointBase {
+

I'd move this into a separate header file with all the other breakpoint 
classes. I think this file is pretty big already and it would help 
readability/maintainability to split things up.



Comment at: tools/lldb-vscode/lldb-vscode.cpp:337
+
+struct State {
+  FILE *in;

Some newlines to group related members and methods would really improve 
readability in this struct.



Comment at: tools/lldb-vscode/lldb-vscode.cpp:350
+  std::thread event_thread;
+//  std::thread forward_input_thread;
+//  std::thread forward_output_thread;

Can we remove this?



Comment at: tools/lldb-vscode/lldb-vscode.cpp:472
+
+#pragma mark -- other utilities
+

Building on my previous suggestion, I'd prefer separate files over these 
pragmas as my editor doesn't understand them.



Comment at: tools/lldb-vscode/lldb-vscode.cpp:512
+const char *get_value(lldb::SBValue &v, std::string &storage) {
+  // Get the value from an SBValue that we will display in VS Code. Some
+  // values don't have C string values and C string summaries. If a value has

I'd move this up and turn it into a doxygen comment.



Comment at: tools/lldb-vscode/lldb-vscode.cpp:924
+ inst_offset, spaces, "", m, o);
+  std::string line;
+  line = str;

Could be a single statement.



Comment at: tools/lldb-vscode/lldb-vscode.cpp:1370
+
+std::string to_string(const JSONValue::SP &object) {
+  if (object) {

Should this live in the json lib?


https://reviews.llvm.org/D50365



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

[Lldb-commits] [PATCH] D50365: Add a new tool named "lldb-vscode" that implements the Visual Studio Code Debug Adaptor Protocol

[Jan Korous via Phabricator via lldb-commits]

jkorous added a comment.

Hi Greg, this looks interesting! I got curious about your patch since I am 
dealing with another protocol from the same "family" - LSP.




Comment at: tools/lldb-vscode/lldb-vscode.cpp:1424
+//--
+std::string read_json_packet(FILE *in) {
+  static std::string header("Content-Length: ");

It looks to me that since you are just logging protocol level error here they 
will manifest as JSON parsing errors down the road (L 4113). Is that ok?

BTW there's another implementation of HTTP-like header parsing in clangd:
https://github.com/llvm-mirror/clang-tools-extra/blob/master/clangd/JSONRPCDispatcher.cpp#L238



Comment at: tools/lldb-vscode/lldb-vscode.cpp:4107
+  uint32_t packet_idx = 0;
+  while (true) {//!feof(g_state.in) && !ferror(g_state.in)) {
+std::string json = read_json_packet(g_state.in);

This looks like some possible forgotten debugging artefact.


https://reviews.llvm.org/D50365



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

[Lldb-commits] [PATCH] D50071: Use rich mangling information in Symtab::InitNameIndexes()

[Jim Ingham via Phabricator via lldb-commits]

jingham added a comment.

You and Pavel have done great work getting this all straight.  I don't have 
much to add except some trivial quibbles about variable naming, a grammar error 
and some other inessentials.




Comment at: include/lldb/Core/Mangled.h:323-325
+  /// @return
+  /// The rich mangling info on success, null otherwise. Expect the pointer
+  /// to be valid only until the next call to this funtion.

The return description isn't right anymore.



Comment at: include/lldb/Core/RichManglingContext.h:98
+
+  /// Cast the given parser to the given type. Ideally we had a type trait
+  /// to deduce \a ParserT from a given InfoProvider, but unfortunately we

had -> would have



Comment at: source/Core/Mangled.cpp:305-306
+  // Check whether or not we are interested in this name at all.
+  llvm::StringRef M = m_mangled.GetStringRef();
+  ManglingScheme S = cstring_mangling_scheme(M.data());
+  if (skip_mangled_name && skip_mangled_name(M, S))

locals in lldb are lower case always, and we really try not to use one letter 
variables (M & S below...)



Comment at: source/Core/Mangled.cpp:239-240
+//--
+namespace {
+
+char *GetMSVCDemangledStr(const char *M) {

The LLVM conventions suggest only putting declarations in the anon namespace, 
and then having the definitions out of line:

http://www.llvm.org/docs/CodingStandards.html#anonymous-namespaces



Comment at: source/Core/RichManglingContext.cpp:147
+  case ItaniumPartialDemangler: {
+auto N = m_ipd_buf_size;
+auto buf = m_ipd.getFunctionDeclContextName(m_ipd_buf, &N);

Again, don't use capitol letter local variables



Comment at: source/Symbol/Symtab.cpp:376-377
+  // Only register functions that have a base name.
+  MC.ParseFunctionBaseName();
+  llvm::StringRef base_name = MC.GetBufferRef();
+  if (base_name.empty())

Not MC either...


https://reviews.llvm.org/D50071



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

[Lldb-commits] [PATCH] D50071: Use rich mangling information in Symtab::InitNameIndexes()

[Stefan Gränitz via Phabricator via lldb-commits]

sgraenitz updated this revision to Diff 159767.
sgraenitz marked 5 inline comments as done.
sgraenitz added a comment.

Addressed Jim's feedback


https://reviews.llvm.org/D50071

Files:
  include/lldb/Core/Mangled.h
  include/lldb/Core/RichManglingContext.h
  include/lldb/Symbol/Symtab.h
  include/lldb/lldb-forward.h
  lldb.xcodeproj/project.pbxproj
  source/Core/CMakeLists.txt
  source/Core/Mangled.cpp
  source/Core/RichManglingContext.cpp
  source/Symbol/Symtab.cpp
  unittests/Core/CMakeLists.txt
  unittests/Core/RichManglingContextTest.cpp

Index: unittests/Core/RichManglingContextTest.cpp
===
--- /dev/null
+++ unittests/Core/RichManglingContextTest.cpp
@@ -0,0 +1,114 @@
+//===-- RichManglingContextTest.cpp -*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "lldb/Core/RichManglingContext.h"
+
+#include "lldb/Utility/ConstString.h"
+
+#include "gtest/gtest.h"
+
+using namespace lldb;
+using namespace lldb_private;
+
+TEST(RichManglingContextTest, Basic) {
+  RichManglingContext RMC;
+  ConstString mangled("_ZN3foo3barEv");
+  EXPECT_TRUE(RMC.FromItaniumName(mangled));
+
+  EXPECT_TRUE(RMC.IsFunction());
+  EXPECT_FALSE(RMC.IsCtorOrDtor());
+
+  RMC.ParseFunctionDeclContextName();
+  EXPECT_EQ("foo", RMC.GetBufferRef());
+
+  RMC.ParseFunctionBaseName();
+  EXPECT_EQ("bar", RMC.GetBufferRef());
+
+  RMC.ParseFullName();
+  EXPECT_EQ("foo::bar()", RMC.GetBufferRef());
+}
+
+TEST(RichManglingContextTest, FromCxxMethodName) {
+  RichManglingContext ItaniumRMC;
+  ConstString mangled("_ZN3foo3barEv");
+  EXPECT_TRUE(ItaniumRMC.FromItaniumName(mangled));
+
+  RichManglingContext CxxMethodRMC;
+  ConstString demangled("foo::bar()");
+  EXPECT_TRUE(CxxMethodRMC.FromCxxMethodName(demangled));
+
+  EXPECT_TRUE(ItaniumRMC.IsFunction() == CxxMethodRMC.IsFunction());
+  EXPECT_TRUE(ItaniumRMC.IsCtorOrDtor() == CxxMethodRMC.IsCtorOrDtor());
+
+  ItaniumRMC.ParseFunctionDeclContextName();
+  CxxMethodRMC.ParseFunctionDeclContextName();
+  EXPECT_TRUE(ItaniumRMC.GetBufferRef() == CxxMethodRMC.GetBufferRef());
+
+  ItaniumRMC.ParseFunctionBaseName();
+  CxxMethodRMC.ParseFunctionBaseName();
+  EXPECT_TRUE(ItaniumRMC.GetBufferRef() == CxxMethodRMC.GetBufferRef());
+
+  ItaniumRMC.ParseFullName();
+  CxxMethodRMC.ParseFullName();
+  EXPECT_TRUE(ItaniumRMC.GetBufferRef() == CxxMethodRMC.GetBufferRef());
+}
+
+TEST(RichManglingContextTest, SwitchProvider) {
+  RichManglingContext RMC;
+  llvm::StringRef mangled = "_ZN3foo3barEv";
+  llvm::StringRef demangled = "foo::bar()";
+
+  EXPECT_TRUE(RMC.FromItaniumName(ConstString(mangled)));
+  RMC.ParseFullName();
+  EXPECT_EQ("foo::bar()", RMC.GetBufferRef());
+
+  EXPECT_TRUE(RMC.FromCxxMethodName(ConstString(demangled)));
+  RMC.ParseFullName();
+  EXPECT_EQ("foo::bar()", RMC.GetBufferRef());
+
+  EXPECT_TRUE(RMC.FromItaniumName(ConstString(mangled)));
+  RMC.ParseFullName();
+  EXPECT_EQ("foo::bar()", RMC.GetBufferRef());
+}
+
+TEST(RichManglingContextTest, IPDRealloc) {
+  // The demangled name should fit into the Itanium default buffer.
+  const char *short_mangled = "_ZN3foo3barEv";
+
+  // The demangled name for this will certainly not fit into the default buffer.
+  const char *long_mangled =
+  "_ZNK3shk6detail17CallbackPublisherIZNS_5ThrowERKNSt15__exception_"
+  "ptr13exception_ptrEEUlOT_E_E9SubscribeINS0_9ConcatMapINS0_"
+  "18CallbackSubscriberIZNS_6GetAllIiNS1_IZZNS_9ConcatMapIZNS_6ConcatIJNS1_"
+  "IZZNS_3MapIZZNS_7IfEmptyIS9_EEDaS7_ENKUlS6_E_clINS1_IZZNS_4TakeIiEESI_"
+  "S7_ENKUlS6_E_clINS1_IZZNS_6FilterIZNS_9ElementAtEmEUlS7_E_EESI_S7_"
+  "ENKUlS6_E_clINS1_IZZNSL_ImEESI_S7_ENKUlS6_E_clINS1_IZNS_4FromINS0_"
+  "22InfiniteRangeContainerIiSI_S7_EUlS7_E_SI_S6_EUlS7_E_SI_S6_"
+  "EUlS7_E_SI_S6_EUlS7_E_SI_S6_EUlS7_E_EESI_S7_ENKUlS6_E_clIS14_"
+  "EESI_S6_EUlS7_E_EERNS1_IZZNSH_IS9_EESI_S7_ENKSK_IS14_EESI_S6_EUlS7_E0_"
+  "ESI_DpOT_EUlS7_E_EESI_S7_ENKUlS6_E_clINS1_IZNS_5StartIJZNS_"
+  "4JustIJS19_S1C_EEESI_S1F_EUlvE_ZNS1K_IJS19_S1C_EEESI_S1F_EUlvE0_EEESI_"
+  "S1F_EUlS7_E_SI_S6_EUlS7_E_St6vectorIS6_SaIS6_EERKT0_NS_"
+  "12ElementCountEbEUlS7_E_ZNSD_IiS1Q_EES1T_S1W_S1X_bEUlOS3_E_ZNSD_IiS1Q_"
+  "EES1T_S1W_S1X_bEUlvE_EES1G_S1O_E25ConcatMapValuesSubscriberEEEDaS7_";
+
+  RichManglingContext RMC;
+
+  // Demangle the short one and remember the buffer address.
+  EXPECT_TRUE(RMC.FromItaniumName(ConstString(short_mangled)));
+  RMC.ParseFullName();
+  const char *short_demangled_ptr = RMC.GetBufferRef().data();
+
+  // Demangle the long one and make sure the buffer address changed.
+  EXPECT_TRUE(RMC.FromItaniumName(ConstString(long_mangled)));
+  RMC.Parse

[Lldb-commits] [PATCH] D50071: Use rich mangling information in Symtab::InitNameIndexes()

[Stefan Gränitz via Phabricator via lldb-commits]

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



Comment at: source/Core/Mangled.cpp:239-240
+//--
+namespace {
+
+char *GetMSVCDemangledStr(const char *M) {

jingham wrote:
> The LLVM conventions suggest only putting declarations in the anon namespace, 
> and then having the definitions out of line:
> 
> http://www.llvm.org/docs/CodingStandards.html#anonymous-namespaces
Right. Well that's a C function, so removed anon namespace and declared static.


https://reviews.llvm.org/D50071



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

[Lldb-commits] [PATCH] D50473: [Demangle] Add another test for ItaniumPartialDemangler

[Stefan Gränitz via Phabricator via lldb-commits]

sgraenitz created this revision.
sgraenitz added a reviewer: erik.pilkington.
Herald added a subscriber: llvm-commits.

Show the behavior of print operations in the ItaniumPartialDemangler. It's a 
summary of what the current integration in LLDB assumes. For new users this may 
be a useful example.


Repository:
  rL LLVM

https://reviews.llvm.org/D50473

Files:
  unittests/Demangle/PartialDemangleTest.cpp


Index: unittests/Demangle/PartialDemangleTest.cpp
===
--- unittests/Demangle/PartialDemangleTest.cpp
+++ unittests/Demangle/PartialDemangleTest.cpp
@@ -145,5 +145,50 @@
   EXPECT_TRUE(D2.isFunction());
 
   EXPECT_TRUE(D1.partialDemangle("Not a mangled name!"));
+}
+
+TEST(PartialDemanglerTest, TestPrintCases) {
+  llvm::ItaniumPartialDemangler D;
+
+  const size_t OriginalSize = 4;
+  char *Buf = static_cast(std::malloc(OriginalSize));
+  const char *OriginalBuf = Buf;
+
+  // Default success case: Result fits into the given buffer.
+  // Res points to Buf. N returns string size including null termination.
+  {
+EXPECT_FALSE(D.partialDemangle("_ZN1a1bEv"));
+
+size_t N = OriginalSize;
+char *Res = D.getFunctionDeclContextName(Buf, &N);
+EXPECT_STREQ("a", Res);
+EXPECT_EQ(OriginalBuf, Res);
+EXPECT_EQ(strlen(Res) + 1, N);
+  }
 
+  // Realloc success case: Result does not fit into the given buffer.
+  // Res points to the new or extended buffer. N returns string size
+  // including null termination. Buf was extended or freed.
+  {
+EXPECT_FALSE(D.partialDemangle("_ZN1a1b1cIiiiEEvm"));
+
+size_t N = OriginalSize;
+char *Res = D.finishDemangle(Buf, &N);
+EXPECT_STREQ("void a::b::c(unsigned long)", Res);
+EXPECT_EQ(strlen(Res) + 1, N);
+Buf = Res;
+  }
+
+  // Failure case: a::c is not a function.
+  // Res is nullptr. N remains unchanged.
+  {
+EXPECT_FALSE(D.partialDemangle("_ZN1a1cE"));
+
+size_t N = OriginalSize;
+char *Res = D.getFunctionName(Buf, &N);
+EXPECT_EQ(nullptr, Res);
+EXPECT_EQ(OriginalSize, N);
+  }
+
+  std::free(Buf);
 }


Index: unittests/Demangle/PartialDemangleTest.cpp
===
--- unittests/Demangle/PartialDemangleTest.cpp
+++ unittests/Demangle/PartialDemangleTest.cpp
@@ -145,5 +145,50 @@
   EXPECT_TRUE(D2.isFunction());
 
   EXPECT_TRUE(D1.partialDemangle("Not a mangled name!"));
+}
+
+TEST(PartialDemanglerTest, TestPrintCases) {
+  llvm::ItaniumPartialDemangler D;
+
+  const size_t OriginalSize = 4;
+  char *Buf = static_cast(std::malloc(OriginalSize));
+  const char *OriginalBuf = Buf;
+
+  // Default success case: Result fits into the given buffer.
+  // Res points to Buf. N returns string size including null termination.
+  {
+EXPECT_FALSE(D.partialDemangle("_ZN1a1bEv"));
+
+size_t N = OriginalSize;
+char *Res = D.getFunctionDeclContextName(Buf, &N);
+EXPECT_STREQ("a", Res);
+EXPECT_EQ(OriginalBuf, Res);
+EXPECT_EQ(strlen(Res) + 1, N);
+  }
 
+  // Realloc success case: Result does not fit into the given buffer.
+  // Res points to the new or extended buffer. N returns string size
+  // including null termination. Buf was extended or freed.
+  {
+EXPECT_FALSE(D.partialDemangle("_ZN1a1b1cIiiiEEvm"));
+
+size_t N = OriginalSize;
+char *Res = D.finishDemangle(Buf, &N);
+EXPECT_STREQ("void a::b::c(unsigned long)", Res);
+EXPECT_EQ(strlen(Res) + 1, N);
+Buf = Res;
+  }
+
+  // Failure case: a::c is not a function.
+  // Res is nullptr. N remains unchanged.
+  {
+EXPECT_FALSE(D.partialDemangle("_ZN1a1cE"));
+
+size_t N = OriginalSize;
+char *Res = D.getFunctionName(Buf, &N);
+EXPECT_EQ(nullptr, Res);
+EXPECT_EQ(OriginalSize, N);
+  }
+
+  std::free(Buf);
 }
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D50271: [IRMemoryMap] Shrink Allocation make it move-only (NFC)

[Davide Italiano via Phabricator via lldb-commits]

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

Looks reasonable to me.


https://reviews.llvm.org/D50271



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

[Lldb-commits] [PATCH] D50365: Add a new tool named "lldb-vscode" that implements the Visual Studio Code Debug Adaptor Protocol

[Greg Clayton via Phabricator via lldb-commits]

clayborg added a comment.

In https://reviews.llvm.org/D50365#1191944, @labath wrote:

> I am not sure I'll have the resources to see this review through, so I'd 
> prefer to leave this to someone else.
>
> The thoughts I have had so far are:
>
> - the patch is very big and probably runs afoul of the "you shall develop 
> incrementally" section in the LLVM developer policy. At least the JSON parts 
> should be split off into a separate patch and tested independently.
> - however, the choice of the JSON library is also an open question. We 
> currently have at least three options to choose from:
>   - llvm/Support/JSON.h
>   - lldb/Utility/JSON.h
>   - debugserver/source/JSON.h
>
> Of these, the third one is the one I'd least expect to be used here.


Ok, I removed the debugserver reliance for the JSON parser and I have recoded 
it to use the LLVM JSON parser. Will post patch soon.

> 
> 
> - Since this is essentially starting a new-subproject, I think it's in place 
> to discuss various conventions. E.g., right now, this seems to use a mixture 
> of UpperCamel and snake_case, and so isn't very consistent with neither llvm 
> nor lldb naming conventions.

I will fix these things before checkin and run clang-format


https://reviews.llvm.org/D50365



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

[Lldb-commits] [PATCH] D50473: [Demangle] Add another test for ItaniumPartialDemangler

[Erik Pilkington via Phabricator via lldb-commits]

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

LGTM, thanks for doing this!




Comment at: unittests/Demangle/PartialDemangleTest.cpp:188
+size_t N = OriginalSize;
+char *Res = D.getFunctionName(Buf, &N);
+EXPECT_EQ(nullptr, Res);

Does LLDB actually pass in a N that is less than the length of Buf? Its not 
wrong to do that per se, realloc will sort it out, but it seems kinda strange.


Repository:
  rL LLVM

https://reviews.llvm.org/D50473



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

[Lldb-commits] [PATCH] D50478: WIP: Basic tail call frame support

[Vedant Kumar via Phabricator via lldb-commits]

vsk created this revision.
Herald added a subscriber: JDevlieghere.

This is a prototype of tail call frame support for lldb based on
compiler support from https://reviews.llvm.org/D49887. It isn't ready for 
review. I'm sharing the
proof-of-concept to give a heads-up about this coming down the pipeline,
and/or to answer any early questions.

Demo (see the included tail5.cc test case):

+ /Users/vsk/src/builds/llvm-project-tailcall-RA/bin//clang++ tail5.cc -o 
tail5.cc.out -g -mllvm -callsite-debuginfo-experimental=true -O2
+ xcrun lldb -o 'b sink' -o r -o bt -o quit tail5.cc.out
(lldb) target create "tail5.cc.out"
Current executable set to 'tail5.cc.out' (x86_64).
(lldb) b sink
Breakpoint 1: where = tail5.cc.out`sink() + 4 at tail5.cc:2, address = 
0x00010f64
(lldb) r
tail5.cc.out was compiled with optimization - stepping may behave oddly; 
variables may not be available.
Process 21540 stopped

- thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 
frame #0: 0x00010f64 tail5.cc.out`sink() at tail5.cc:2 [opt] 1
volatile int x;

-> 2void __attribute__((noinline)) sink() { x++; }

  3void __attribute__((noinline)) D() { sink(); /* tail */ }
  4void __attribute__((disable_tail_calls, noinline)) C() { D(); /* regular 
*/ }
  5void __attribute__((noinline)) B() { C(); /* tail */ }
  6int __attribute__((disable_tail_calls)) main() { B(); /* regular */ }

Target 0: (tail5.cc.out) stopped.

Process 21540 launched: 
'/Users/vsk/src/llvm-project-tailcall/lldb/test/testcases/functionalities/tail_call_frames/tail5.cc.out'
 (x86_64)
(lldb) bt

- thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
  - frame #0: 0x00010f64 tail5.cc.out`sink() at tail5.cc:2 [opt] frame 
#1: 0x00010f89 tail5.cc.out`C() at tail5.cc:4 [opt] frame #2: 
0x00010fa9 tail5.cc.out`main at tail5.cc:6 [opt] frame #3: 
0x7fff57147015 libdyld.dylib`start + 1 frame #4: 0x7fff57147015 
libdyld.dylib`start + 1

(lldb) quit
+ /Users/vsk/src/builds/llvm-project-tailcall-RA/bin//lldb -o 'b sink' -o r -o 
'log enable -f tail5.cc.log lldb step' -o bt -o quit tail5.cc.out
(lldb) target create "tail5.cc.out"
Current executable set to 'tail5.cc.out' (x86_64).
(lldb) b sink
Breakpoint 1: where = tail5.cc.out`sink() + 4 at tail5.cc:2, address = 
0x00010f64
(lldb) r
tail5.cc.out was compiled with optimization - stepping may behave oddly; 
variables may not be available.
Process 21544 stopped

- thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 
frame #0: 0x00010f64 tail5.cc.out`sink() at tail5.cc:2 [opt] 1
volatile int x;

-> 2void __attribute__((noinline)) sink() { x++; }

  3void __attribute__((noinline)) D() { sink(); /* tail */ }
  4void __attribute__((disable_tail_calls, noinline)) C() { D(); /* regular 
*/ }
  5void __attribute__((noinline)) B() { C(); /* tail */ }
  6int __attribute__((disable_tail_calls)) main() { B(); /* regular */ }

Process 21544 launched: 
'/Users/vsk/src/llvm-project-tailcall/lldb/test/testcases/functionalities/tail_call_frames/tail5.cc.out'
 (x86_64)
(lldb) log enable -f tail5.cc.log lldb step
(lldb) bt

- thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
  - frame #0: 0x00010f64 tail5.cc.out`sink() at tail5.cc:2 [opt] frame 
#1: 0x0010 tail5.cc.out`D() - 4294971232 [opt] frame #2: 
0x00010f89 tail5.cc.out`C() at tail5.cc:4 [opt] frame #3: 
0x0030 tail5.cc.out`B() - 4294971232 [opt] frame #4: 
0x00010fa9 tail5.cc.out`main at tail5.cc:6 [opt] frame #5: 
0x7fff57147015 libdyld.dylib`start + 1 frame #6: 0x7fff57147015 
libdyld.dylib`start + 1


https://reviews.llvm.org/D50478

Files:
  lldb/include/lldb/Symbol/Block.h
  lldb/include/lldb/Symbol/Function.h
  lldb/include/lldb/Symbol/SymbolFile.h
  lldb/include/lldb/Target/StackFrame.h
  lldb/include/lldb/Target/StackFrameList.h
  lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/tail.cc
  lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/tail2.cc
  lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/tail3.cc
  lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/tail4.cc
  lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/tail5.cc
  lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/test.sh
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
  lldb/source/Symbol/Block.cpp
  lldb/source/Symbol/Function.cpp
  lldb/source/Target/StackFrameList.cpp

Index: lldb/source/Target/StackFrameList.cpp
===
--- lldb/source/Target/StackFrameList.cpp
+++ lldb/source/Target/StackFrameList.cpp
@@ -27,6 +27,7 @@
 #include "lldb/Target/Thread.h"
 #include "lldb/Target/Unwind.h"
 #include "lldb/Utility/Log.h"
+#include "llvm/A

[Lldb-commits] [PATCH] D50071: Use rich mangling information in Symtab::InitNameIndexes()

[Jim Ingham via Phabricator via lldb-commits]

jingham accepted this revision.
jingham added a comment.

Looks good.


https://reviews.llvm.org/D50071



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

[Lldb-commits] [lldb] r339290 - [IRMemoryMap] Shrink Allocation and make it move-only (NFC)

[Vedant Kumar via lldb-commits]

Author: vedantk
Date: Wed Aug  8 14:26:49 2018
New Revision: 339290

URL: http://llvm.org/viewvc/llvm-project?rev=339290&view=rev
Log:
[IRMemoryMap] Shrink Allocation and make it move-only (NFC)

Profiling data show that Allocation::operator= is hot (see the data
attached to the Phab review).

Reorder a few fields within Allocation to avoid implicit structure
padding and shrink the structure. This should make copies a bit cheaper.

Also, given that an Allocation contains a std::vector (by way of
DataBufferHeap), it's preferable to make it move-only instead of
permitting expensive copies. As an added benefit this allows us to have
a single Allocation constructor instead of two.

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

Modified:
lldb/trunk/include/lldb/Expression/IRMemoryMap.h
lldb/trunk/source/Expression/IRMemoryMap.cpp

Modified: lldb/trunk/include/lldb/Expression/IRMemoryMap.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Expression/IRMemoryMap.h?rev=339290&r1=339289&r2=339290&view=diff
==
--- lldb/trunk/include/lldb/Expression/IRMemoryMap.h (original)
+++ lldb/trunk/include/lldb/Expression/IRMemoryMap.h Wed Aug  8 14:26:49 2018
@@ -39,7 +39,7 @@ public:
   IRMemoryMap(lldb::TargetSP target_sp);
   ~IRMemoryMap();
 
-  enum AllocationPolicy {
+  enum AllocationPolicy : uint8_t {
 eAllocationPolicyInvalid =
 0, ///< It is an error for an allocation to have this policy.
 eAllocationPolicyHostOnly, ///< This allocation was created in the host and
@@ -91,32 +91,32 @@ protected:
 private:
   struct Allocation {
 lldb::addr_t
-m_process_alloc; ///< The (unaligned) base for the remote allocation
+m_process_alloc; ///< The (unaligned) base for the remote allocation.
 lldb::addr_t
-m_process_start; ///< The base address of the allocation in the process
-size_t m_size;   ///< The size of the requested allocation
-uint32_t m_permissions; ///< The access permissions on the memory in the
-///process.  In the host, the memory is always
-///read/write.
-uint8_t m_alignment;///< The alignment of the requested allocation
+m_process_start; ///< The base address of the allocation in the 
process.
+size_t m_size;   ///< The size of the requested allocation.
 DataBufferHeap m_data;
 
-///< Flags
+/// Flags. Keep these grouped together to avoid structure padding.
 AllocationPolicy m_policy;
 bool m_leak;
+uint8_t m_permissions; ///< The access permissions on the memory in the
+   /// process. In the host, the memory is always
+   /// read/write.
+uint8_t m_alignment;   ///< The alignment of the requested allocation.
 
   public:
 Allocation(lldb::addr_t process_alloc, lldb::addr_t process_start,
size_t size, uint32_t permissions, uint8_t alignment,
AllocationPolicy m_policy);
 
-Allocation()
-: m_process_alloc(LLDB_INVALID_ADDRESS),
-  m_process_start(LLDB_INVALID_ADDRESS), m_size(0), m_permissions(0),
-  m_alignment(0), m_data(), m_policy(eAllocationPolicyInvalid),
-  m_leak(false) {}
+DISALLOW_COPY_AND_ASSIGN(Allocation);
   };
 
+  static_assert(sizeof(Allocation) <=
+(4 * sizeof(lldb::addr_t)) + sizeof(DataBufferHeap),
+"IRMemoryMap::Allocation is larger than expected");
+
   lldb::ProcessWP m_process_wp;
   lldb::TargetWP m_target_wp;
   typedef std::map AllocationMap;

Modified: lldb/trunk/source/Expression/IRMemoryMap.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Expression/IRMemoryMap.cpp?rev=339290&r1=339289&r2=339290&view=diff
==
--- lldb/trunk/source/Expression/IRMemoryMap.cpp (original)
+++ lldb/trunk/source/Expression/IRMemoryMap.cpp Wed Aug  8 14:26:49 2018
@@ -272,8 +272,8 @@ IRMemoryMap::Allocation::Allocation(lldb
 uint32_t permissions, uint8_t alignment,
 AllocationPolicy policy)
 : m_process_alloc(process_alloc), m_process_start(process_start),
-  m_size(size), m_permissions(permissions), m_alignment(alignment),
-  m_policy(policy), m_leak(false) {
+  m_size(size), m_policy(policy), m_leak(false), 
m_permissions(permissions),
+  m_alignment(alignment) {
   switch (policy) {
   default:
 assert(0 && "We cannot reach this!");
@@ -389,9 +389,10 @@ lldb::addr_t IRMemoryMap::Malloc(size_t
   lldb::addr_t mask = alignment - 1;
   aligned_address = (allocation_address + mask) & (~mask);
 
-  m_allocations[aligned_address] =
-  Allocation(allocation_address, aligned_address, allocation_size,
- permissions, alignment, policy);
+  m_allocations.emplace(
+  std::piecewi

[Lldb-commits] [PATCH] D50271: [IRMemoryMap] Shrink Allocation make it move-only (NFC)

[Phabricator via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL339290: [IRMemoryMap] Shrink Allocation and make it 
move-only (NFC) (authored by vedantk, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D50271?vs=159339&id=159797#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D50271

Files:
  lldb/trunk/include/lldb/Expression/IRMemoryMap.h
  lldb/trunk/source/Expression/IRMemoryMap.cpp


Index: lldb/trunk/include/lldb/Expression/IRMemoryMap.h
===
--- lldb/trunk/include/lldb/Expression/IRMemoryMap.h
+++ lldb/trunk/include/lldb/Expression/IRMemoryMap.h
@@ -39,7 +39,7 @@
   IRMemoryMap(lldb::TargetSP target_sp);
   ~IRMemoryMap();
 
-  enum AllocationPolicy {
+  enum AllocationPolicy : uint8_t {
 eAllocationPolicyInvalid =
 0, ///< It is an error for an allocation to have this policy.
 eAllocationPolicyHostOnly, ///< This allocation was created in the host and
@@ -91,32 +91,32 @@
 private:
   struct Allocation {
 lldb::addr_t
-m_process_alloc; ///< The (unaligned) base for the remote allocation
+m_process_alloc; ///< The (unaligned) base for the remote allocation.
 lldb::addr_t
-m_process_start; ///< The base address of the allocation in the process
-size_t m_size;   ///< The size of the requested allocation
-uint32_t m_permissions; ///< The access permissions on the memory in the
-///process.  In the host, the memory is always
-///read/write.
-uint8_t m_alignment;///< The alignment of the requested allocation
+m_process_start; ///< The base address of the allocation in the 
process.
+size_t m_size;   ///< The size of the requested allocation.
 DataBufferHeap m_data;
 
-///< Flags
+/// Flags. Keep these grouped together to avoid structure padding.
 AllocationPolicy m_policy;
 bool m_leak;
+uint8_t m_permissions; ///< The access permissions on the memory in the
+   /// process. In the host, the memory is always
+   /// read/write.
+uint8_t m_alignment;   ///< The alignment of the requested allocation.
 
   public:
 Allocation(lldb::addr_t process_alloc, lldb::addr_t process_start,
size_t size, uint32_t permissions, uint8_t alignment,
AllocationPolicy m_policy);
 
-Allocation()
-: m_process_alloc(LLDB_INVALID_ADDRESS),
-  m_process_start(LLDB_INVALID_ADDRESS), m_size(0), m_permissions(0),
-  m_alignment(0), m_data(), m_policy(eAllocationPolicyInvalid),
-  m_leak(false) {}
+DISALLOW_COPY_AND_ASSIGN(Allocation);
   };
 
+  static_assert(sizeof(Allocation) <=
+(4 * sizeof(lldb::addr_t)) + sizeof(DataBufferHeap),
+"IRMemoryMap::Allocation is larger than expected");
+
   lldb::ProcessWP m_process_wp;
   lldb::TargetWP m_target_wp;
   typedef std::map AllocationMap;
Index: lldb/trunk/source/Expression/IRMemoryMap.cpp
===
--- lldb/trunk/source/Expression/IRMemoryMap.cpp
+++ lldb/trunk/source/Expression/IRMemoryMap.cpp
@@ -272,8 +272,8 @@
 uint32_t permissions, uint8_t alignment,
 AllocationPolicy policy)
 : m_process_alloc(process_alloc), m_process_start(process_start),
-  m_size(size), m_permissions(permissions), m_alignment(alignment),
-  m_policy(policy), m_leak(false) {
+  m_size(size), m_policy(policy), m_leak(false), 
m_permissions(permissions),
+  m_alignment(alignment) {
   switch (policy) {
   default:
 assert(0 && "We cannot reach this!");
@@ -389,9 +389,10 @@
   lldb::addr_t mask = alignment - 1;
   aligned_address = (allocation_address + mask) & (~mask);
 
-  m_allocations[aligned_address] =
-  Allocation(allocation_address, aligned_address, allocation_size,
- permissions, alignment, policy);
+  m_allocations.emplace(
+  std::piecewise_construct, std::forward_as_tuple(aligned_address),
+  std::forward_as_tuple(allocation_address, aligned_address,
+allocation_size, permissions, alignment, policy));
 
   if (zero_memory) {
 Status write_error;


Index: lldb/trunk/include/lldb/Expression/IRMemoryMap.h
===
--- lldb/trunk/include/lldb/Expression/IRMemoryMap.h
+++ lldb/trunk/include/lldb/Expression/IRMemoryMap.h
@@ -39,7 +39,7 @@
   IRMemoryMap(lldb::TargetSP target_sp);
   ~IRMemoryMap();
 
-  enum AllocationPolicy {
+  enum AllocationPolicy : uint8_t {
 eAllocationPolicyInvalid =
 0, ///< It is an error for an allocation to have this policy.
 eAllocationPolicyHostOnly, ///< This allocation was created in the host and
@@ -91,32 +91,32 @

[Lldb-commits] [lldb] r339292 - Add ConstString test FromMidOfBufferStringRef

[Stefan Granitz via lldb-commits]

Author: stefan.graenitz
Date: Wed Aug  8 14:57:42 2018
New Revision: 339292

URL: http://llvm.org/viewvc/llvm-project?rev=339292&view=rev
Log:
Add ConstString test FromMidOfBufferStringRef

Summary: It was not immediately clear to me whether or not non-null-terminated 
StringRef's are supported in ConstString and/or the counterpart mechanism. From 
this test it seems to be fine. Maybe useful to keep?

Reviewers: labath

Subscribers: lldb-commits

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

Modified:
lldb/trunk/unittests/Utility/ConstStringTest.cpp

Modified: lldb/trunk/unittests/Utility/ConstStringTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/Utility/ConstStringTest.cpp?rev=339292&r1=339291&r2=339292&view=diff
==
--- lldb/trunk/unittests/Utility/ConstStringTest.cpp (original)
+++ lldb/trunk/unittests/Utility/ConstStringTest.cpp Wed Aug  8 14:57:42 2018
@@ -34,6 +34,26 @@ TEST(ConstStringTest, MangledCounterpart
   EXPECT_EQ("bar", counterpart.GetStringRef());
 }
 
+TEST(ConstStringTest, FromMidOfBufferStringRef) {
+  // StringRef's into bigger buffer: no null termination
+  const char *buffer = "foobarbaz";
+  llvm::StringRef foo_ref(buffer, 3);
+  llvm::StringRef bar_ref(buffer + 3, 3);
+
+  ConstString foo(foo_ref);
+
+  ConstString bar;
+  bar.SetStringWithMangledCounterpart(bar_ref, foo);
+  EXPECT_EQ("bar", bar.GetStringRef());
+
+  ConstString counterpart;
+  EXPECT_TRUE(bar.GetMangledCounterpart(counterpart));
+  EXPECT_EQ("foo", counterpart.GetStringRef());
+
+  EXPECT_TRUE(foo.GetMangledCounterpart(counterpart));
+  EXPECT_EQ("bar", counterpart.GetStringRef());
+}
+
 TEST(ConstStringTest, NullAndEmptyStates) {
   ConstString foo("foo");
   EXPECT_FALSE(!foo);


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

[Lldb-commits] [lldb] r339291 - Use rich mangling information in Symtab::InitNameIndexes()

[Stefan Granitz via lldb-commits]

Author: stefan.graenitz
Date: Wed Aug  8 14:57:37 2018
New Revision: 339291

URL: http://llvm.org/viewvc/llvm-project?rev=339291&view=rev
Log:
Use rich mangling information in Symtab::InitNameIndexes()

Summary:
I set up a new review, because not all the code I touched was marked as a 
change in old one anymore.

In preparation for this review, there were two earlier ones:
* https://reviews.llvm.org/D49612 introduced the ItaniumPartialDemangler to 
LLDB demangling without conceptual changes
* https://reviews.llvm.org/D49909 added a unit test that covers all relevant 
code paths in the InitNameIndexes() function

Primary goals for this patch are:
(1) Use ItaniumPartialDemangler's rich mangling info for building LLDB's name 
index.
(2) Provide a uniform interface.
(3) Improve indexing performance.

The central implementation in this patch is our new function for explicit 
demangling:
```
const RichManglingInfo *
Mangled::DemangleWithRichManglingInfo(RichManglingContext &, SkipMangledNameFn 
*)
```

It takes a context object and a filter function and provides read-only access 
to the rich mangling info on success, or otherwise returns null. The two new 
classes are:
* `RichManglingInfo` offers a uniform interface to query symbol properties like 
`getFunctionDeclContextName()` or `isCtorOrDtor()` that are forwarded to the 
respective provider internally (`llvm::ItaniumPartialDemangler` or 
`lldb_private::CPlusPlusLanguage::MethodName`).
* `RichManglingContext` works a bit like `LLVMContext`, it the actual 
`RichManglingInfo` returned from `DemangleWithRichManglingInfo()` and handles 
lifetime and configuration. It is likely stack-allocated and can be reused for 
multiple queries during batch processing.

The idea here is that `DemangleWithRichManglingInfo()` acts like a gate keeper. 
It only provides access to `RichManglingInfo` on success, which in turn avoids 
the need to handle a `NoInfo` state in every single one of its getters. Having 
it stored within the context, avoids extra heap allocations and aids (3). As 
instantiations of the IPD the are considered expensive, the context is the 
ideal place to store it too. An efficient filtering function 
`SkipMangledNameFn` is another piece in the performance puzzle and it helps to 
mimic the original behavior of `InitNameIndexes`.

Future potential:
* `DemangleWithRichManglingInfo()` is thread-safe, IFF using different contexts 
in different threads. This may be exploited in the future. (It's another thing 
that it has in common with `LLVMContext`.)
* The old implementation only parsed and indexed Itanium mangled names. The new 
`RichManglingInfo` can be extended for various mangling schemes and languages.

One problem with the implementation of RichManglingInfo is the inaccessibility 
of class `CPlusPlusLanguage::MethodName` (defined in 
source/Plugins/Language/..), from within any header in the Core components of 
LLDB. The rather hacky solution is to store a type erased reference and cast it 
to the correct type on access in the cpp - see 
`RichManglingInfo::get()`. At the moment there seems to be no better 
way to do it. IMHO `CPlusPlusLanguage::MethodName` should be a top-level class 
in order to enable forward delcarations (but that is a rather big change I 
guess).

First simple profiling shows a good speedup. `target create clang` now takes 
0.64s on average. Before the change I observed runtimes between 0.76s an 1.01s. 
This is still no bulletproof data (I only ran it on one machine!), but it's a 
promising indicator I think.

Reviewers: labath, jingham, JDevlieghere, erik.pilkington

Subscribers: zturner, clayborg, mgorny, lldb-commits

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

Added:
lldb/trunk/include/lldb/Core/RichManglingContext.h
lldb/trunk/source/Core/RichManglingContext.cpp
lldb/trunk/unittests/Core/RichManglingContextTest.cpp
Modified:
lldb/trunk/include/lldb/Core/Mangled.h
lldb/trunk/include/lldb/Symbol/Symtab.h
lldb/trunk/include/lldb/lldb-forward.h
lldb/trunk/lldb.xcodeproj/project.pbxproj
lldb/trunk/source/Core/CMakeLists.txt
lldb/trunk/source/Core/Mangled.cpp
lldb/trunk/source/Symbol/Symtab.cpp
lldb/trunk/unittests/Core/CMakeLists.txt

Modified: lldb/trunk/include/lldb/Core/Mangled.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/Mangled.h?rev=339291&r1=339290&r2=339291&view=diff
==
--- lldb/trunk/include/lldb/Core/Mangled.h (original)
+++ lldb/trunk/include/lldb/Core/Mangled.h Wed Aug  8 14:57:37 2018
@@ -11,18 +11,15 @@
 #define liblldb_Mangled_h_
 #if defined(__cplusplus)
 
+#include "lldb/lldb-enumerations.h"
+#include "lldb/lldb-forward.h"
+
 #include "lldb/Utility/ConstString.h"
-#include "lldb/lldb-enumerations.h" // for LanguageType
-#include "llvm/ADT/StringRef.h" // for StringRef
 
-#include  // for size_t
+#include "llvm/ADT/StringRef.h"
 
-namespace lldb_private {
-cl

[Lldb-commits] [PATCH] D50071: Use rich mangling information in Symtab::InitNameIndexes()

[Phabricator via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL339291: Use rich mangling information in 
Symtab::InitNameIndexes() (authored by stefan.graenitz, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D50071?vs=159767&id=159804#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D50071

Files:
  lldb/trunk/include/lldb/Core/Mangled.h
  lldb/trunk/include/lldb/Core/RichManglingContext.h
  lldb/trunk/include/lldb/Symbol/Symtab.h
  lldb/trunk/include/lldb/lldb-forward.h
  lldb/trunk/lldb.xcodeproj/project.pbxproj
  lldb/trunk/source/Core/CMakeLists.txt
  lldb/trunk/source/Core/Mangled.cpp
  lldb/trunk/source/Core/RichManglingContext.cpp
  lldb/trunk/source/Symbol/Symtab.cpp
  lldb/trunk/unittests/Core/CMakeLists.txt
  lldb/trunk/unittests/Core/RichManglingContextTest.cpp

Index: lldb/trunk/include/lldb/Symbol/Symtab.h
===
--- lldb/trunk/include/lldb/Symbol/Symtab.h
+++ lldb/trunk/include/lldb/Symbol/Symtab.h
@@ -197,6 +197,15 @@
   void SymbolIndicesToSymbolContextList(std::vector &symbol_indexes,
 SymbolContextList &sc_list);
 
+  void RegisterMangledNameEntry(
+  NameToIndexMap::Entry &entry, std::set &class_contexts,
+  std::vector> &backlog,
+  RichManglingContext &rmc);
+
+  void RegisterBacklogEntry(const NameToIndexMap::Entry &entry,
+const char *decl_context,
+const std::set &class_contexts);
+
   DISALLOW_COPY_AND_ASSIGN(Symtab);
 };
 
Index: lldb/trunk/include/lldb/lldb-forward.h
===
--- lldb/trunk/include/lldb/lldb-forward.h
+++ lldb/trunk/include/lldb/lldb-forward.h
@@ -191,6 +191,7 @@
 class RegisterValue;
 class RegularExpression;
 class REPL;
+class RichManglingContext;
 class Scalar;
 class ScriptInterpreter;
 class ScriptInterpreterLocker;
@@ -492,5 +493,15 @@
 
 } // namespace lldb
 
+//--
+// llvm forward declarations
+//--
+namespace llvm {
+
+struct ItaniumPartialDemangler;
+class StringRef;
+
+} // namespace llvm
+
 #endif // #if defined(__cplusplus)
 #endif // LLDB_lldb_forward_h_
Index: lldb/trunk/include/lldb/Core/RichManglingContext.h
===
--- lldb/trunk/include/lldb/Core/RichManglingContext.h
+++ lldb/trunk/include/lldb/Core/RichManglingContext.h
@@ -0,0 +1,110 @@
+//===-- RichManglingContext.h ---*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef liblldb_RichManglingContext_h_
+#define liblldb_RichManglingContext_h_
+
+#include "lldb/lldb-forward.h"
+#include "lldb/lldb-private.h"
+
+#include "lldb/Utility/ConstString.h"
+
+#include "llvm/ADT/Any.h"
+#include "llvm/ADT/SmallString.h"
+#include "llvm/Demangle/Demangle.h"
+
+namespace lldb_private {
+
+/// Uniform wrapper for access to rich mangling information from different
+/// providers. See Mangled::DemangleWithRichManglingInfo()
+class RichManglingContext {
+public:
+  RichManglingContext()
+  : m_provider(None), m_ipd_buf_size(2048), m_ipd_str_len(0) {
+m_ipd_buf = static_cast(std::malloc(m_ipd_buf_size));
+m_ipd_buf[m_ipd_str_len] = '\0';
+  }
+
+  ~RichManglingContext() { std::free(m_ipd_buf); }
+
+  /// Use the ItaniumPartialDemangler to obtain rich mangling information from
+  /// the given mangled name.
+  bool FromItaniumName(const ConstString &mangled);
+
+  /// Use the legacy language parser implementation to obtain rich mangling
+  /// information from the given demangled name.
+  bool FromCxxMethodName(const ConstString &demangled);
+
+  /// If this symbol describes a constructor or destructor.
+  bool IsCtorOrDtor() const;
+
+  /// If this symbol describes a function.
+  bool IsFunction() const;
+
+  /// Get the base name of a function. This doesn't include trailing template
+  /// arguments, ie "a::b" gives "b". The result will overwrite the
+  /// internal buffer. It can be obtained via GetBufferRef().
+  void ParseFunctionBaseName();
+
+  /// Get the context name for a function. For "a::b::c", this function returns
+  /// "a::b". The result will overwrite the internal buffer. It can be obtained
+  /// via GetBufferRef().
+  void ParseFunctionDeclContextName();
+
+  /// Get the entire demangled name. The result will overwrite the internal
+  /// buffer. It can be obtained via GetBufferRef().
+  void ParseFullName();
+
+  /// Obtain a StringRef to the internal buffer that holds the result of the
+  /// most 

[Lldb-commits] [PATCH] D50334: Add ConstString test FromMidOfBufferStringRef

[Phabricator via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rLLDB339292: Add ConstString test FromMidOfBufferStringRef 
(authored by stefan.graenitz, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D50334?vs=159298&id=159806#toc

Repository:
  rLLDB LLDB

https://reviews.llvm.org/D50334

Files:
  unittests/Utility/ConstStringTest.cpp


Index: unittests/Utility/ConstStringTest.cpp
===
--- unittests/Utility/ConstStringTest.cpp
+++ unittests/Utility/ConstStringTest.cpp
@@ -34,6 +34,26 @@
   EXPECT_EQ("bar", counterpart.GetStringRef());
 }
 
+TEST(ConstStringTest, FromMidOfBufferStringRef) {
+  // StringRef's into bigger buffer: no null termination
+  const char *buffer = "foobarbaz";
+  llvm::StringRef foo_ref(buffer, 3);
+  llvm::StringRef bar_ref(buffer + 3, 3);
+
+  ConstString foo(foo_ref);
+
+  ConstString bar;
+  bar.SetStringWithMangledCounterpart(bar_ref, foo);
+  EXPECT_EQ("bar", bar.GetStringRef());
+
+  ConstString counterpart;
+  EXPECT_TRUE(bar.GetMangledCounterpart(counterpart));
+  EXPECT_EQ("foo", counterpart.GetStringRef());
+
+  EXPECT_TRUE(foo.GetMangledCounterpart(counterpart));
+  EXPECT_EQ("bar", counterpart.GetStringRef());
+}
+
 TEST(ConstStringTest, NullAndEmptyStates) {
   ConstString foo("foo");
   EXPECT_FALSE(!foo);


Index: unittests/Utility/ConstStringTest.cpp
===
--- unittests/Utility/ConstStringTest.cpp
+++ unittests/Utility/ConstStringTest.cpp
@@ -34,6 +34,26 @@
   EXPECT_EQ("bar", counterpart.GetStringRef());
 }
 
+TEST(ConstStringTest, FromMidOfBufferStringRef) {
+  // StringRef's into bigger buffer: no null termination
+  const char *buffer = "foobarbaz";
+  llvm::StringRef foo_ref(buffer, 3);
+  llvm::StringRef bar_ref(buffer + 3, 3);
+
+  ConstString foo(foo_ref);
+
+  ConstString bar;
+  bar.SetStringWithMangledCounterpart(bar_ref, foo);
+  EXPECT_EQ("bar", bar.GetStringRef());
+
+  ConstString counterpart;
+  EXPECT_TRUE(bar.GetMangledCounterpart(counterpart));
+  EXPECT_EQ("foo", counterpart.GetStringRef());
+
+  EXPECT_TRUE(foo.GetMangledCounterpart(counterpart));
+  EXPECT_EQ("bar", counterpart.GetStringRef());
+}
+
 TEST(ConstStringTest, NullAndEmptyStates) {
   ConstString foo("foo");
   EXPECT_FALSE(!foo);
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D50473: [Demangle] Add another test for ItaniumPartialDemangler

[Stefan Gränitz via Phabricator via lldb-commits]

sgraenitz added inline comments.



Comment at: unittests/Demangle/PartialDemangleTest.cpp:188
+size_t N = OriginalSize;
+char *Res = D.getFunctionName(Buf, &N);
+EXPECT_EQ(nullptr, Res);

erik.pilkington wrote:
> Does LLDB actually pass in a N that is less than the length of Buf? Its not 
> wrong to do that per se, realloc will sort it out, but it seems kinda strange.
My first version used only one variable for N, so the pretended buffer size was 
decreasing continuously while the actual buffer remained unchanged.. That 
caused unnecessary allocations. I fixed that a few days ago. Basically it's 
these three cases to consider:
https://github.com/llvm-mirror/lldb/blob/a063373af4d295e48017ca218d1030aac13b0af5/source/Core/RichManglingContext.cpp#L91


Repository:
  rL LLVM

https://reviews.llvm.org/D50473



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

[Lldb-commits] [PATCH] D50473: [Demangle] Add another test for ItaniumPartialDemangler

[Phabricator via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL339297: [Demangle] Add another test for 
ItaniumPartialDemangler (authored by stefan.graenitz, committed by ).

Repository:
  rL LLVM

https://reviews.llvm.org/D50473

Files:
  llvm/trunk/unittests/Demangle/PartialDemangleTest.cpp


Index: llvm/trunk/unittests/Demangle/PartialDemangleTest.cpp
===
--- llvm/trunk/unittests/Demangle/PartialDemangleTest.cpp
+++ llvm/trunk/unittests/Demangle/PartialDemangleTest.cpp
@@ -145,5 +145,50 @@
   EXPECT_TRUE(D2.isFunction());
 
   EXPECT_TRUE(D1.partialDemangle("Not a mangled name!"));
+}
+
+TEST(PartialDemanglerTest, TestPrintCases) {
+  llvm::ItaniumPartialDemangler D;
+
+  const size_t OriginalSize = 4;
+  char *Buf = static_cast(std::malloc(OriginalSize));
+  const char *OriginalBuf = Buf;
+
+  // Default success case: Result fits into the given buffer.
+  // Res points to Buf. N returns string size including null termination.
+  {
+EXPECT_FALSE(D.partialDemangle("_ZN1a1bEv"));
+
+size_t N = OriginalSize;
+char *Res = D.getFunctionDeclContextName(Buf, &N);
+EXPECT_STREQ("a", Res);
+EXPECT_EQ(OriginalBuf, Res);
+EXPECT_EQ(strlen(Res) + 1, N);
+  }
 
+  // Realloc success case: Result does not fit into the given buffer.
+  // Res points to the new or extended buffer. N returns string size
+  // including null termination. Buf was extended or freed.
+  {
+EXPECT_FALSE(D.partialDemangle("_ZN1a1b1cIiiiEEvm"));
+
+size_t N = OriginalSize;
+char *Res = D.finishDemangle(Buf, &N);
+EXPECT_STREQ("void a::b::c(unsigned long)", Res);
+EXPECT_EQ(strlen(Res) + 1, N);
+Buf = Res;
+  }
+
+  // Failure case: a::c is not a function.
+  // Res is nullptr. N remains unchanged.
+  {
+EXPECT_FALSE(D.partialDemangle("_ZN1a1cE"));
+
+size_t N = OriginalSize;
+char *Res = D.getFunctionName(Buf, &N);
+EXPECT_EQ(nullptr, Res);
+EXPECT_EQ(OriginalSize, N);
+  }
+
+  std::free(Buf);
 }


Index: llvm/trunk/unittests/Demangle/PartialDemangleTest.cpp
===
--- llvm/trunk/unittests/Demangle/PartialDemangleTest.cpp
+++ llvm/trunk/unittests/Demangle/PartialDemangleTest.cpp
@@ -145,5 +145,50 @@
   EXPECT_TRUE(D2.isFunction());
 
   EXPECT_TRUE(D1.partialDemangle("Not a mangled name!"));
+}
+
+TEST(PartialDemanglerTest, TestPrintCases) {
+  llvm::ItaniumPartialDemangler D;
+
+  const size_t OriginalSize = 4;
+  char *Buf = static_cast(std::malloc(OriginalSize));
+  const char *OriginalBuf = Buf;
+
+  // Default success case: Result fits into the given buffer.
+  // Res points to Buf. N returns string size including null termination.
+  {
+EXPECT_FALSE(D.partialDemangle("_ZN1a1bEv"));
+
+size_t N = OriginalSize;
+char *Res = D.getFunctionDeclContextName(Buf, &N);
+EXPECT_STREQ("a", Res);
+EXPECT_EQ(OriginalBuf, Res);
+EXPECT_EQ(strlen(Res) + 1, N);
+  }
 
+  // Realloc success case: Result does not fit into the given buffer.
+  // Res points to the new or extended buffer. N returns string size
+  // including null termination. Buf was extended or freed.
+  {
+EXPECT_FALSE(D.partialDemangle("_ZN1a1b1cIiiiEEvm"));
+
+size_t N = OriginalSize;
+char *Res = D.finishDemangle(Buf, &N);
+EXPECT_STREQ("void a::b::c(unsigned long)", Res);
+EXPECT_EQ(strlen(Res) + 1, N);
+Buf = Res;
+  }
+
+  // Failure case: a::c is not a function.
+  // Res is nullptr. N remains unchanged.
+  {
+EXPECT_FALSE(D.partialDemangle("_ZN1a1cE"));
+
+size_t N = OriginalSize;
+char *Res = D.getFunctionName(Buf, &N);
+EXPECT_EQ(nullptr, Res);
+EXPECT_EQ(OriginalSize, N);
+  }
+
+  std::free(Buf);
 }
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D50481: Fix broken builtin functions in the expression command

[Raphael Isemann via Phabricator via lldb-commits]

teemperor created this revision.

Calling any non-libc builtin function in the expression command currently just 
causes Clang
to state that the function is not known. The reason for this is that we 
actually never
initialize the list of builtin functions in the Builtin::Context.

This patch just calls the initializer for the builtins in the preprocessor. 
Also adds some tests
for the new builtins.

It also gets rid of the extra list of builtins in the ClangExpressionParser, as 
we can just reuse
the existing list in the Preprocessor for the ASTContext. Having just one list 
of builtins around
is also closer to the standard Clang behavior.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D50481

Files:
  
packages/Python/lldbsuite/test/expression_command/call-function/TestCallBuiltinFunction.py
  source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
  source/Plugins/ExpressionParser/Clang/ClangExpressionParser.h


Index: source/Plugins/ExpressionParser/Clang/ClangExpressionParser.h
===
--- source/Plugins/ExpressionParser/Clang/ClangExpressionParser.h
+++ source/Plugins/ExpressionParser/Clang/ClangExpressionParser.h
@@ -149,8 +149,6 @@
   m_file_manager; ///< The Clang file manager object used by the compiler
   std::unique_ptr
   m_compiler; ///< The Clang compiler used to parse expressions into IR
-  std::unique_ptr
-  m_builtin_context; ///< Context for Clang built-ins
   std::unique_ptr
   m_selector_table; ///< Selector table for Objective-C methods
   std::unique_ptr
Index: source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
===
--- source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
+++ source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
@@ -508,12 +508,21 @@
   // 8. Most of this we get from the CompilerInstance, but we also want to give
   // the context an ExternalASTSource.
   m_selector_table.reset(new SelectorTable());
-  m_builtin_context.reset(new Builtin::Context());
+
+  // We enable all builtin functions beside the builtins from libc/libm (e.g.
+  // 'fopen'). Those libc functions are already correctly handled by LLDB, and
+  // additionally enabling them as expandable builtins is breaking Clang.
+  m_compiler->getLangOpts().NoBuiltin = true;
+
+  auto &PP = m_compiler->getPreprocessor();
+  PP.getBuiltinInfo().initializeBuiltins(PP.getIdentifierTable(),
+ m_compiler->getLangOpts());
+  auto &builtin_context = PP.getBuiltinInfo();
 
   std::unique_ptr ast_context(
   new ASTContext(m_compiler->getLangOpts(), m_compiler->getSourceManager(),
  m_compiler->getPreprocessor().getIdentifierTable(),
- *m_selector_table.get(), *m_builtin_context.get()));
+ *m_selector_table.get(), builtin_context));
 
   ast_context->InitBuiltinTypes(m_compiler->getTarget());
 
Index: 
packages/Python/lldbsuite/test/expression_command/call-function/TestCallBuiltinFunction.py
===
--- /dev/null
+++ 
packages/Python/lldbsuite/test/expression_command/call-function/TestCallBuiltinFunction.py
@@ -0,0 +1,41 @@
+"""
+Test calling builtin functions using expression evaluation.
+
+"""
+
+from __future__ import print_function
+
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class ExprCommandCallBuiltinFunction(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def setUp(self):
+TestBase.setUp(self)
+# Find the line number to break for main.c.
+self.line = line_number(
+'main.cpp',
+'// Please test these expressions while stopped at this line:')
+
+def test(self):
+"""Test return values of user defined function calls."""
+self.build()
+
+# Set breakpoint in main and run exe
+self.runCmd("file " + self.getBuildArtifact("a.out"), 
CURRENT_EXECUTABLE_SET)
+lldbutil.run_break_set_by_file_and_line(
+self, "main.cpp", self.line, num_expected_locations=-1, 
loc_exact=True)
+
+self.runCmd("run", RUN_SUCCEEDED)
+
+# Test different builtin functions.
+self.expect("expr __builtin_isinf(0.0f)", substrs=['(int) $0 = 0'])
+self.expect("expr __builtin_isnormal(0.0f)", substrs=['(int) $1 = 0'])
+self.expect("expr __builtin_constant_p(1)", substrs=['(int) $2 = 1'])
+self.expect("expr __builtin_abs(-14)", substrs=['(int) $3 = 14'])


Index: source/Plugins/ExpressionParser/Clang/ClangExpressionParser.h
===
--- source/Plugins/ExpressionParser/Clang/ClangExpressionParser.h
+++ source/Plugins/ExpressionParser/Clang/ClangExpressionParser.h
@@ -149,8 +149,6 @@
   m_file_manag

[Lldb-commits] [PATCH] D50481: Fix broken builtin functions in the expression command

[Raphael Isemann via Phabricator via lldb-commits]

teemperor added a reviewer: jingham.
teemperor added a comment.

I didn't disable Windows on the test as it shouldn't call any function in the 
target process. Just because I don't want to x-fail every test on Windows.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D50481



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

Re: [Lldb-commits] [PATCH] D50365: Add a new tool named "lldb-vscode" that implements the Visual Studio Code Debug Adaptor Protocol

[Leonard Mosescu via lldb-commits]

>
> The LLDB MI plugin didn't work very well as was quite flaky when I tested
> it a while back.
>

Just curious, what was the flaky part, the debug adapter or the LLDB MI
interface?

On Wed, Aug 8, 2018 at 8:40 AM, Greg Clayton via Phabricator <
revi...@reviews.llvm.org> wrote:

> clayborg added a comment.
>
> In https://reviews.llvm.org/D50365#1192447, @zturner wrote:
>
> > To elaborate, if you install the C/C++ plugin, and you go to Debug ->
> >  Configurations, and you go down to the MICmdMode property, it is by
> default
> >  set to "gdb".  But you can change this to "lldb" and it works out of the
> >  box.
>
>
> It is a different protocol. The LLDB MI plugin didn't work very well as
> was quite flaky when I tested it a while back. Then I grabbed the CodeLLDB
> plugin by Vadim Chugunov and it worked very well. When I looked more
> closely at this plugin, it was using a javascript/typescript plug-in to
> launch a LLDB instance and then ran a python script that received all of
> the javascript packets from the javascript/typescript based plug-in and ran
> the debug session using the python interpreter. It worked very well and was
> rock solid stable. So I then created this plug-in for Nuclide for use at
> Facebook as they switched all of the debugging plug-in over to use the
> VSCode debug adaptor protocols. It works event better than the CodeLLDB
> plugin with Visual Studio Code and it also doesn't stop you from using the
> python interpreter. The issue I had with the CodeLLDB is that is uses the
> python interpreter to run the debug session thus it isn't available to you
> as a LLDB user.
>
> So long story short: our IDE at Facebook uses the VSCode protocol, MI is
> clunky and doesn't work that well and was flaky, so this tool was created.
> This also provides a really nice way to do remote debugging where the
> lldb-vscode is run remotely on other systems. This removes the need for
> copying files from a remote host up onto the system that is doing the
> debugging. So we use this at Facebook and it also provides the best way to
> use LLDB to debug using Visual Studio Code or Nuclide.
>
>
> https://reviews.llvm.org/D50365
>
>
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D50365: Add a new tool named "lldb-vscode" that implements the Visual Studio Code Debug Adaptor Protocol

[Leonard Mosescu via Phabricator via lldb-commits]

lemo added a subscriber: zturner.
lemo added a comment.

> The LLDB MI plugin didn't work very well as was quite flaky when I tested
>  it a while back.

Just curious, what was the flaky part, the debug adapter or the LLDB MI
interface?


https://reviews.llvm.org/D50365



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

[Lldb-commits] [PATCH] D50365: Add a new tool named "lldb-vscode" that implements the Visual Studio Code Debug Adaptor Protocol

[Jason Molenda via Phabricator via lldb-commits]

jasonmolenda added a comment.

Haven't had time to read through the main part of the patch, but I think the 
changes to debugserver's JSON parser would be good additions even if you've 
switched away from using it.  The debugserver JSON parser is a copy of lldb's 
with all the StringRef etc llvm classes removed quickly, so it's always been a 
bit of a mess, I should have forked it from before any of the llvm stuff 
started being integrated.


https://reviews.llvm.org/D50365



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

[Lldb-commits] [PATCH] D50492: Also display the output and error output of a failed command

[Raphael Isemann via Phabricator via lldb-commits]

teemperor created this revision.

Instead of just printing the current "False is not True, ..." message when we
fail to run a certain command, this patch also adds the actual command output or
error output that we received to the assertion message.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D50492

Files:
  packages/Python/lldbsuite/test/lldbtest.py


Index: packages/Python/lldbsuite/test/lldbtest.py
===
--- packages/Python/lldbsuite/test/lldbtest.py
+++ packages/Python/lldbsuite/test/lldbtest.py
@@ -2074,8 +2074,13 @@
 print("Command '" + cmd + "' failed!", file=sbuf)
 
 if check:
+output = ""
+if self.res.GetOutput():
+  output += "\nCommand output:\n" + self.res.GetOutput()
+if self.res.GetError():
+  output += "\nError output:\n" + self.res.GetError()
 self.assertTrue(self.res.Succeeded(),
-msg if msg else CMD_MSG(cmd))
+msg if (msg + output) else CMD_MSG(cmd + output))
 
 def match(
 self,


Index: packages/Python/lldbsuite/test/lldbtest.py
===
--- packages/Python/lldbsuite/test/lldbtest.py
+++ packages/Python/lldbsuite/test/lldbtest.py
@@ -2074,8 +2074,13 @@
 print("Command '" + cmd + "' failed!", file=sbuf)
 
 if check:
+output = ""
+if self.res.GetOutput():
+  output += "\nCommand output:\n" + self.res.GetOutput()
+if self.res.GetError():
+  output += "\nError output:\n" + self.res.GetError()
 self.assertTrue(self.res.Succeeded(),
-msg if msg else CMD_MSG(cmd))
+msg if (msg + output) else CMD_MSG(cmd + output))
 
 def match(
 self,
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits