Re: [Lldb-commits] [lldb] r333700 - [IRMemoryMap] Test interleaved Mallocs and Frees

2018-06-01 Thread Pavel Labath via lldb-commits 
On Thu, 31 May 2018 at 23:13, Vedant Kumar via lldb-commits
 wrote:
>
> Author: vedantk
> Date: Thu May 31 15:09:01 2018
> New Revision: 333700
>
> URL: http://llvm.org/viewvc/llvm-project?rev=333700&view=rev
> Log:
> [IRMemoryMap] Test interleaved Mallocs and Frees
>
> This adds a new command to the ir-memory-map tester:
>
>   free 
>
> The argument to free is an index which identifies which live allocation
> to free. Index 0 identifies the first live allocation in the address
> space, index 1 identifies the second, etc. where the allocations are
> sorted in increasing order.
>
> For illustrative purposes, assume malloc returns monotonically
> increasing addresses. Here are some examples of how free would work:
>
> Example 1
> -
>
> malloc 16 1
> malloc 32 1
> free 1  //< Free the 32-byte allocation.
> free 0  //< Next, free the 16-byte allocation.

I think it would be better if the mallocs and frees were connected
symbolically instead of by an index that changes after every free. In
the long test case you add here it's pretty much impossible to figure
out which allocation a particular free refers to. Maybe we could
attach an optional "label" to each malloc statement and then have
"free" reference those? e.g. something like:
LARGEALLOC: malloc 4096 16
malloc 10, 1 # I won't free this, no label necessary
free LARGEALLOC # frees first allocation

Adding parsing code for the extended syntax shouldn't be much work,
but I believe it will help a lot with the readability of these test
cases.

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

[Lldb-commits] [PATCH] D47612: Add dependency on clang-headers when building LLDB.framework using CMake

2018-06-01 Thread 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 don't understand the interactions between lldb framework and clang headers, 
but if there isn't a better person to review this, I'm happy to rubber-stamp 
it. :)


https://reviews.llvm.org/D47612



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

[Lldb-commits] [PATCH] D47470: AppleDWARFIndex: Get function method-ness directly from debug info

2018-06-01 Thread Pavel Labath via Phabricator via lldb-commits 
labath updated this revision to Diff 149423.
labath marked an inline comment as done.
labath added a comment.

I have a feeling we are starting to over-engineer this. Visiting referenced dies
sounds like a useful utility in general, though I think most of the users will
be content with just visiting the attributes of those dies (and that's a
functionality we already have). Nonetheless, I implemented something like that.
I made it an iterator-based api, as callback-based apis are generally more
complicated to use.


https://reviews.llvm.org/D47470

Files:
  lit/SymbolFile/DWARF/find-method-local-struct.cpp
  source/Plugins/SymbolFile/DWARF/AppleDWARFIndex.cpp
  source/Plugins/SymbolFile/DWARF/DWARFDIE.cpp
  source/Plugins/SymbolFile/DWARF/DWARFDIE.h
  source/Plugins/SymbolFile/DWARF/ManualDWARFIndex.cpp

Index: source/Plugins/SymbolFile/DWARF/ManualDWARFIndex.cpp
===
--- source/Plugins/SymbolFile/DWARF/ManualDWARFIndex.cpp
+++ source/Plugins/SymbolFile/DWARF/ManualDWARFIndex.cpp
@@ -288,22 +288,7 @@
   }
   // If we have a mangled name, then the DW_AT_name attribute is
   // usually the method name without the class or any parameters
-  const DWARFDebugInfoEntry *parent = die.GetParent();
-  bool is_method = false;
-  if (parent) {
-DWARFDIE parent_die(&unit, parent);
-if (parent_die.IsStructClassOrUnion())
-  is_method = true;
-else {
-  if (specification_die_form.IsValid()) {
-DWARFDIE specification_die =
-unit.GetSymbolFileDWARF()->DebugInfo()->GetDIE(
-DIERef(specification_die_form));
-if (specification_die.GetParent().IsStructClassOrUnion())
-  is_method = true;
-  }
-}
-  }
+  bool is_method = DWARFDIE(&unit, &die).IsMethod();
 
   if (is_method)
 set.function_methods.Insert(ConstString(name),
Index: source/Plugins/SymbolFile/DWARF/DWARFDIE.h
===
--- source/Plugins/SymbolFile/DWARF/DWARFDIE.h
+++ source/Plugins/SymbolFile/DWARF/DWARFDIE.h
@@ -11,15 +11,20 @@
 #define SymbolFileDWARF_DWARFDIE_h_
 
 #include "DWARFBaseDIE.h"
+#include "llvm/ADT/SmallSet.h"
 
 class DWARFDIE : public DWARFBaseDIE {
 public:
+  class ElaboratingDIEIterator;
+
   using DWARFBaseDIE::DWARFBaseDIE;
 
   //--
   // Tests
   //--
-  bool IsStructClassOrUnion() const;
+  bool IsStructUnionOrClass() const;
+
+  bool IsMethod() const;
 
   //--
   // Accessors
@@ -29,6 +34,8 @@
   DWARFDIE
   GetContainingDWOModuleDIE() const;
 
+  inline llvm::iterator_range elaborating_dies() const;
+
   //--
   // Accessing information about a DIE
   //--
@@ -112,4 +119,58 @@
   lldb_private::CompilerDeclContext GetContainingDeclContext() const;
 };
 
+/// Iterate through all DIEs elaborating (i.e. reachable by a chain of
+/// DW_AT_specification and DW_AT_abstract_origin attributes) a given DIE. For
+/// convenience, the starting die is included in the sequence as the first
+/// item.
+class DWARFDIE::ElaboratingDIEIterator
+: public std::iterator {
+
+  // The operating invariant is: top of m_worklist contains the "current" item
+  // and the rest of the list are items yet to be visited. An empty worklist
+  // means we've reached the end.
+  // Infinite recursion is prevented by maintaining a list of seen DIEs.
+  // Container sizes are optimized for the case of following DW_AT_specification
+  // and DW_AT_abstract_origin just once.
+  llvm::SmallVector m_worklist;
+  llvm::SmallSet m_seen;
+
+  void Next();
+
+public:
+  /// An iterator starting at die d.
+  explicit ElaboratingDIEIterator(DWARFDIE d) : m_worklist(1, d) {}
+
+  /// End marker
+  ElaboratingDIEIterator() {}
+
+  const DWARFDIE &operator*() const { return m_worklist.back(); }
+  ElaboratingDIEIterator &operator++() {
+Next();
+return *this;
+  }
+  ElaboratingDIEIterator operator++(int) {
+ElaboratingDIEIterator I = *this;
+Next();
+return I;
+  }
+
+  friend bool operator==(const ElaboratingDIEIterator &a,
+ const ElaboratingDIEIterator &b) {
+if (a.m_worklist.empty() || b.m_worklist.empty())
+  return a.m_worklist.empty() == b.m_worklist.empty();
+return a.m_worklist.back() == b.m_worklist.back();
+  }
+  friend bool operator!=(const ElaboratingDIEIterator &a,
+ const ElaboratingDIEIterator &b) {
+return !(a == b);
+  }
+};
+
+llvm::iterator_range
+DWARFDIE::elaborating_d

[Lldb-commits] [PATCH] D47470: AppleDWARFIndex: Get function method-ness directly from debug info

2018-06-01 Thread Pavel Labath via Phabricator via lldb-commits 
labath added a comment.

ps: the specificationsAndAbstractOrigins sounded like too big of a mouthful. 
I've invented the name "elaborating dies" for that.


https://reviews.llvm.org/D47470



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

[Lldb-commits] [PATCH] D47625: [cmake] Detect presence of wide-char libedit at build time

2018-06-01 Thread Pavel Labath via Phabricator via lldb-commits 
labath created this revision.
labath added reviewers: krytarowski, uweigand, jankratochvil, timshen, beanz.
Herald added a subscriber: mgorny.

Instead of hardcoding a list of platforms where libedit is known to have
wide char support we detect this in cmake. The main motivation for this
is attempting to improve compatibility with different versions of
libedit, as the interface of non-wide-char functions varies slightly
between versions.

This should be NFC on all platforms except linux. On linux, we used to
hardcode to non-wide-char, now we will use wide-char if we detect
libedit supports that.


https://reviews.llvm.org/D47625

Files:
  cmake/modules/LLDBGenerateConfig.cmake
  include/lldb/Host/Config.h
  include/lldb/Host/Config.h.cmake
  include/lldb/Host/Editline.h


Index: include/lldb/Host/Editline.h
===
--- include/lldb/Host/Editline.h
+++ include/lldb/Host/Editline.h
@@ -33,23 +33,11 @@
 #define liblldb_Editline_h_
 #if defined(__cplusplus)
 
+#include 
 #include 
 #include 
 #include 
 
-// components needed to handle wide characters ( , codecvt_utf8,
-// libedit built with '--enable-widec' ) are available on some platforms. The
-// wchar_t versions of libedit functions will only be used in cases where this
-// is true.  This is a compile time dependecy, for now selected per target
-// Platform
-#if defined(__APPLE__) || defined(__FreeBSD__) || defined(__NetBSD__) ||   
\
-defined(__OpenBSD__)
-#define LLDB_EDITLINE_USE_WCHAR 1
-#include 
-#else
-#define LLDB_EDITLINE_USE_WCHAR 0
-#endif
-
 #include "lldb/Host/ConnectionFileDescriptor.h"
 #include "lldb/lldb-private.h"
 
Index: include/lldb/Host/Config.h.cmake
===
--- include/lldb/Host/Config.h.cmake
+++ include/lldb/Host/Config.h.cmake
@@ -12,6 +12,8 @@
 
 #cmakedefine LLDB_CONFIG_TERMIOS_SUPPORTED
 
+#cmakedefine01 LLDB_EDITLINE_USE_WCHAR
+
 #cmakedefine LLDB_DISABLE_POSIX
 
 #define LLDB_LIBDIR_SUFFIX "${LLVM_LIBDIR_SUFFIX}"
Index: include/lldb/Host/Config.h
===
--- include/lldb/Host/Config.h
+++ include/lldb/Host/Config.h
@@ -16,6 +16,8 @@
 // absence of a configuration step.
 #define LLDB_CONFIG_TERMIOS_SUPPORTED 1
 
+#define LLDB_EDITLINE_USE_WCHAR 1
+
 #define HAVE_SYS_EVENT_H 1
 
 #define HAVE_PPOLL 0
Index: cmake/modules/LLDBGenerateConfig.cmake
===
--- cmake/modules/LLDBGenerateConfig.cmake
+++ cmake/modules/LLDBGenerateConfig.cmake
@@ -33,6 +33,16 @@
   set(LLDB_DISABLE_POSIX 1)
 endif()
 
+if (NOT LLDB_DISABLE_LIBEDIT)
+  # Check if we libedit capable of handling wide characters (built with
+  # '--enable-widec').
+  set(CMAKE_REQUIRED_LIBRARIES ${libedit_LIBRARIES})
+  set(CMAKE_REQUIRED_INCLUDES ${libedit_INCLUDE_DIRS})
+  check_symbol_exists(el_winsertstr histedit.h LLDB_EDITLINE_USE_WCHAR)
+  set(CMAKE_REQUIRED_LIBRARIES)
+  set(CMAKE_REQUIRED_INCLUDES)
+endif()
+
 if(NOT LLDB_CONFIG_HEADER_INPUT)
  set(LLDB_CONFIG_HEADER_INPUT ${LLDB_INCLUDE_ROOT}/lldb/Host/Config.h.cmake)
 endif()


Index: include/lldb/Host/Editline.h
===
--- include/lldb/Host/Editline.h
+++ include/lldb/Host/Editline.h
@@ -33,23 +33,11 @@
 #define liblldb_Editline_h_
 #if defined(__cplusplus)
 
+#include 
 #include 
 #include 
 #include 
 
-// components needed to handle wide characters ( , codecvt_utf8,
-// libedit built with '--enable-widec' ) are available on some platforms. The
-// wchar_t versions of libedit functions will only be used in cases where this
-// is true.  This is a compile time dependecy, for now selected per target
-// Platform
-#if defined(__APPLE__) || defined(__FreeBSD__) || defined(__NetBSD__) ||   \
-defined(__OpenBSD__)
-#define LLDB_EDITLINE_USE_WCHAR 1
-#include 
-#else
-#define LLDB_EDITLINE_USE_WCHAR 0
-#endif
-
 #include "lldb/Host/ConnectionFileDescriptor.h"
 #include "lldb/lldb-private.h"
 
Index: include/lldb/Host/Config.h.cmake
===
--- include/lldb/Host/Config.h.cmake
+++ include/lldb/Host/Config.h.cmake
@@ -12,6 +12,8 @@
 
 #cmakedefine LLDB_CONFIG_TERMIOS_SUPPORTED
 
+#cmakedefine01 LLDB_EDITLINE_USE_WCHAR
+
 #cmakedefine LLDB_DISABLE_POSIX
 
 #define LLDB_LIBDIR_SUFFIX "${LLVM_LIBDIR_SUFFIX}"
Index: include/lldb/Host/Config.h
===
--- include/lldb/Host/Config.h
+++ include/lldb/Host/Config.h
@@ -16,6 +16,8 @@
 // absence of a configuration step.
 #define LLDB_CONFIG_TERMIOS_SUPPORTED 1
 
+#define LLDB_EDITLINE_USE_WCHAR 1
+
 #define HAVE_SYS_EVENT_H 1
 
 #define HAVE_PPOLL 0
Index: cmake/modules/LLDBGenerateConfig.cmake
===
--- cmake/modules/LLDBGenerateConfig.cmake
+++ cmake/modules/LLDBGenerateConfig.cmak

[Lldb-commits] [PATCH] D47625: [cmake] Detect presence of wide-char libedit at build time

2018-06-01 Thread Pavel Labath via Phabricator via lldb-commits 
labath added inline comments.



Comment at: include/lldb/Host/Editline.h:72-76
 #ifdef EL_CLIENTDATA   /* editline with wide support + wide char read function 
*/
 using EditLineGetCharType = wchar_t;
 #else
 using EditLineGetCharType = char;
 #endif

It's not fully clear to me whether this part is still correct. My understanding 
is that if we use `el_wset` to set the getchar callback, we should always use 
wchar_t, regardless of libedit version. This is only true if all wide-char 
capable libedit versions also define EL_CLIENTDATA.

Is this the case?


https://reviews.llvm.org/D47625



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

Re: [Lldb-commits] [lldb] r303907 - Fix bug #28898

2018-06-01 Thread Pavel Labath via lldb-commits 
Thanks for confirming that. I have created
 which tries to implement this. Could
you take quick look at that? There is one particular question about
EL_CLIENTDATA that I would like to hear your thoughts on.
On Thu, 31 May 2018 at 12:47, Christos Zoulas  wrote:
>
> On May 31, 10:31am, lab...@google.com (Pavel Labath) wrote:
> -- Subject: Re: [Lldb-commits] [lldb] r303907 - Fix bug #28898
>
> | I hate to resurrect an old thread, but there has been a new spurt of
> | this discussion about this patch here
> | .
> |
> | I think I have an idea on how to improve things slightly for us here,
> | but as I know very little about this issue, I'd like someone to take a
> | look at this first.
> |
> | Christos, can you check whether my proposal makes sense to you? I am
> | including it in this email for your convenience:
> |
> |
> | ===
> | I've re-read the last years discussions, and I think I have an idea on
> | how to improve the situation here somewhat. The way I understand it,
> | we have three scenarios to worry about:
> |
> | 1. old-libedit --enable-widec
> |   - el_gets -> narrow_read_function
> |   - el_wgets -> wide_read_function
> | 2. new-libedit --enable-widec
> |   - el_gets -> wide_read_function
> |   - el_wgets -> wide_read_function
> | 3. libedit --disable-widec
> |   - I don't actually know what happens here but my proposal does not
> | change our behavior in this case.
> |
> | As I understand it, the problem is that we are not able to distinguish
> | between (1) and (2) and build time, so we have to just pick one and
> | hope it works. This means we work correctly for (1), we fail for (2)
> | and something unknown happens for (3).
> |
> | However, we **are** able to distinguish between (1+2) and (3) at build
> | time (just search for `el_wgets` symbol). And, if I understand it
> | correctly, when we use el_wgets and friends we are always correct, no
> | matter the libedit version. This would mean are always correct for
> | both (1) **and** (2), while the situation remains unchanged for (3).
> | This should be a strict improvement over status quo.
>
> I think that you are right. Nevertheless what you propose it should
> be an improvement over the status quo.
>
> christos
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r333743 - Add .debug_names section glue code

2018-06-01 Thread Pavel Labath via lldb-commits 
Author: labath
Date: Fri Jun  1 05:06:45 2018
New Revision: 333743

URL: http://llvm.org/viewvc/llvm-project?rev=333743&view=rev
Log:
Add .debug_names section glue code

Modified:
lldb/trunk/include/lldb/lldb-enumerations.h
lldb/trunk/lit/Modules/elf-section-types.yaml
lldb/trunk/source/Core/Section.cpp
lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
lldb/trunk/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
lldb/trunk/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
lldb/trunk/source/Symbol/ObjectFile.cpp

Modified: lldb/trunk/include/lldb/lldb-enumerations.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/lldb-enumerations.h?rev=333743&r1=333742&r2=333743&view=diff
==
--- lldb/trunk/include/lldb/lldb-enumerations.h (original)
+++ lldb/trunk/include/lldb/lldb-enumerations.h Fri Jun  1 05:06:45 2018
@@ -657,6 +657,7 @@ enum SectionType {
// address
   eSectionTypeDWARFGNUDebugAltLink,
   eSectionTypeDWARFDebugTypes, // DWARF .debug_types section
+  eSectionTypeDWARFDebugNames, // DWARF v5 .debug_names
   eSectionTypeOther
 };
 

Modified: lldb/trunk/lit/Modules/elf-section-types.yaml
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Modules/elf-section-types.yaml?rev=333743&r1=333742&r2=333743&view=diff
==
--- lldb/trunk/lit/Modules/elf-section-types.yaml (original)
+++ lldb/trunk/lit/Modules/elf-section-types.yaml Fri Jun  1 05:06:45 2018
@@ -14,6 +14,11 @@
 # CHECK-NEXT: VM size: 0
 # CHECK-NEXT: File size: 8
 
+# CHECK: Name: .debug_names
+# CHECK-NEXT: Type: dwarf-names
+# CHECK-NEXT: VM size: 0
+# CHECK-NEXT: File size: 8
+
 # CHECK: Name: .gnu_debugaltlink
 # CHECK-NEXT: Type: dwarf-gnu-debugaltlink
 # CHECK-NEXT: VM size: 0
@@ -42,6 +47,10 @@ Sections:
 Type:SHT_PROGBITS
 AddressAlign:0x0001
 Content: DEADBEEFBAADF00D
+  - Name:.debug_names
+Type:SHT_PROGBITS
+AddressAlign:0x0001
+Content: DEADBEEFBAADF00D
   - Name:.gnu_debugaltlink
 Type:SHT_PROGBITS
 AddressAlign:0x0001

Modified: lldb/trunk/source/Core/Section.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/Section.cpp?rev=333743&r1=333742&r2=333743&view=diff
==
--- lldb/trunk/source/Core/Section.cpp (original)
+++ lldb/trunk/source/Core/Section.cpp Fri Jun  1 05:06:45 2018
@@ -91,6 +91,8 @@ const char *Section::GetTypeAsCString()
 return "dwarf-str-offsets";
   case eSectionTypeDWARFDebugTypes:
 return "dwarf-types";
+  case eSectionTypeDWARFDebugNames:
+return "dwarf-names";
   case eSectionTypeELFSymbolTable:
 return "elf-symbol-table";
   case eSectionTypeELFDynamicSymbols:

Modified: lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp?rev=333743&r1=333742&r2=333743&view=diff
==
--- lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp (original)
+++ lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp Fri Jun  1 
05:06:45 2018
@@ -1791,6 +1791,7 @@ void ObjectFileELF::CreateSections(Secti
   static ConstString g_sect_name_dwarf_debug_loc(".debug_loc");
   static ConstString g_sect_name_dwarf_debug_macinfo(".debug_macinfo");
   static ConstString g_sect_name_dwarf_debug_macro(".debug_macro");
+  static ConstString g_sect_name_dwarf_debug_names(".debug_names");
   static ConstString g_sect_name_dwarf_debug_pubnames(".debug_pubnames");
   static ConstString g_sect_name_dwarf_debug_pubtypes(".debug_pubtypes");
   static ConstString g_sect_name_dwarf_debug_ranges(".debug_ranges");
@@ -1866,6 +1867,8 @@ void ObjectFileELF::CreateSections(Secti
 sect_type = eSectionTypeDWARFDebugMacInfo;
   else if (name == g_sect_name_dwarf_debug_macro)
 sect_type = eSectionTypeDWARFDebugMacro;
+  else if (name == g_sect_name_dwarf_debug_names)
+sect_type = eSectionTypeDWARFDebugNames;
   else if (name == g_sect_name_dwarf_debug_pubnames)
 sect_type = eSectionTypeDWARFDebugPubNames;
   else if (name == g_sect_name_dwarf_debug_pubtypes)

Modified: lldb/trunk/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp?rev=333743&r1=333742&r2=333743&view=diff
==
--- lldb/trunk/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp (original)
+++ lldb/trunk/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp Fri J

[Lldb-commits] [PATCH] D47629: [DWARF] Add (empty) DebugNamesDWARFIndex class and a setting to control its use

2018-06-01 Thread Pavel Labath via Phabricator via lldb-commits 
labath created this revision.
labath added reviewers: JDevlieghere, clayborg, jingham.
Herald added subscribers: aprantl, mehdi_amini, mgorny.

This patch is pretty much a big noop. It adds the ability to create a
DebugNamesDWARFIndex class, but the class itself is not implemented in
any useful way. The I am putting it up this way is because of the
setting to control whether it gets used. My idea for it was the
following:

- while the feature is under development (which hopefully won't take much 
longer), it will default to off. Tests will override it to true.
- once the feature is complete and we are reasonably certain it works, we flip 
the switch to "on" while keeping the ability to turn it off for troubleshooting 
purposes.
- after it has been on for a release or two and it hasn't blown up into 
anyone's face, we remove the setting altogether.


https://reviews.llvm.org/D47629

Files:
  source/Plugins/SymbolFile/DWARF/CMakeLists.txt
  source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.cpp
  source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.h
  source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp

Index: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
===
--- source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -64,6 +64,7 @@
 #include "DWARFDeclContext.h"
 #include "DWARFFormValue.h"
 #include "DWARFUnit.h"
+#include "DebugNamesDWARFIndex.h"
 #include "LogChannelDWARF.h"
 #include "ManualDWARFIndex.h"
 #include "SymbolFileDWARFDebugMap.h"
@@ -117,15 +118,30 @@
 
 enum { ePropertySymLinkPaths };
 
+PropertyDefinition g_experimental_properties[] = {
+{"use-debug-names", OptionValue::eTypeBoolean, true, 0, nullptr, nullptr,
+ "Use .debug_names index section."},
+{nullptr, OptionValue::eTypeInvalid, false, 0, nullptr, nullptr, nullptr},
+};
+enum { ePropertyDebugNames };
+
 class PluginProperties : public Properties {
+  OptionValuePropertiesSP m_experimental_sp;
+
 public:
   static ConstString GetSettingName() {
 return SymbolFileDWARF::GetPluginNameStatic();
   }
 
   PluginProperties() {
 m_collection_sp.reset(new OptionValueProperties(GetSettingName()));
 m_collection_sp->Initialize(g_properties);
+ConstString experimental_name(Properties::GetExperimentalSettingsName());
+m_experimental_sp = std::make_shared(experimental_name);
+m_experimental_sp->Initialize(g_experimental_properties);
+m_collection_sp->AppendProperty(
+ConstString(Properties::GetExperimentalSettingsName()),
+ConstString("Experimental settings"), true, m_experimental_sp);
   }
 
   FileSpecList &GetSymLinkPaths() {
@@ -135,6 +151,11 @@
 assert(option_value);
 return option_value->GetCurrentValue();
   }
+
+  bool UseDebugNames() const {
+return m_experimental_sp->GetPropertyAtIndexAsBoolean(
+nullptr, ePropertyDebugNames, false);
+  }
 };
 
 typedef std::shared_ptr SymbolFileDWARFPropertiesSP;
@@ -432,6 +453,7 @@
 }
 
 void SymbolFileDWARF::InitializeObject() {
+  Log *log = LogChannelDWARF::GetLogIfAll(DWARF_LOG_DEBUG_INFO);
   ModuleSP module_sp(m_obj_file->GetModule());
   if (module_sp) {
 const SectionList *section_list = module_sp->GetSectionList();
@@ -452,9 +474,26 @@
 apple_namespaces, apple_types, apple_objc,
 get_debug_str_data());
 
-  if (!m_index)
-m_index = llvm::make_unique(*GetObjectFile()->GetModule(),
-  DebugInfo());
+  if (m_index)
+return;
+
+  DWARFDataExtractor debug_names;
+  LoadSectionData(eSectionTypeDWARFDebugNames, debug_names);
+  if (debug_names.GetByteSize() > 0 &&
+  GetGlobalPluginProperties()->UseDebugNames()) {
+llvm::Expected> index_or =
+DebugNamesDWARFIndex::Create(*GetObjectFile()->GetModule(), debug_names,
+ get_debug_str_data(), DebugInfo());
+if (index_or) {
+  m_index = std::move(*index_or);
+  return;
+}
+LLDB_LOG_ERROR(log, index_or.takeError(),
+   "Unable to read .debug_names data: {0}");
+  }
+
+  m_index = llvm::make_unique(*GetObjectFile()->GetModule(),
+DebugInfo());
 }
 
 bool SymbolFileDWARF::SupportedVersion(uint16_t version) {
Index: source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.h
===
--- /dev/null
+++ source/Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.h
@@ -0,0 +1,74 @@
+//===-- DebugNamesDWARFIndex.h -*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef LLDB_DEBUGNAMESDWAR

[Lldb-commits] [PATCH] D47625: [cmake] Detect presence of wide-char libedit at build time

2018-06-01 Thread Jan Kratochvil via Phabricator via lldb-commits 
jankratochvil accepted this revision.
jankratochvil added a comment.
This revision is now accepted and ready to land.

No regressions on Fedora 28 x86_64.  It does set there now 
`LLDB_EDITLINE_USE_WCHAR` although one still cannot enter unicode characters to 
`(lldb)` line.


https://reviews.llvm.org/D47625



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

[Lldb-commits] [PATCH] D47625: [cmake] Detect presence of wide-char libedit at build time

2018-06-01 Thread Kamil Rytarowski via Phabricator via lldb-commits 
krytarowski added a comment.

The original reason to switch NetBSD to wide characters was to unbreak the 
input parser. It used to mix wide and short characters.

Typing unicode characters doesn't work well here too (before applying the 
patch):

`(lldb) za\U+017C\U+0142\U+0107 g\U+0119\U+015Bl\U+0105 ja\U+017A\U+0144`


https://reviews.llvm.org/D47625



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

[Lldb-commits] [PATCH] D47470: AppleDWARFIndex: Get function method-ness directly from debug info

2018-06-01 Thread Greg Clayton via Phabricator via lldb-commits 
clayborg accepted this revision.
clayborg added a comment.

I can't think of a better name, looks good. Thanks for taking the time, this 
will be great.


https://reviews.llvm.org/D47470



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

[Lldb-commits] [PATCH] D47625: [cmake] Detect presence of wide-char libedit at build time

2018-06-01 Thread Christos Zoulas via Phabricator via lldb-commits 
christos added inline comments.



Comment at: include/lldb/Host/Editline.h:72-76
 #ifdef EL_CLIENTDATA   /* editline with wide support + wide char read function 
*/
 using EditLineGetCharType = wchar_t;
 #else
 using EditLineGetCharType = char;
 #endif

labath wrote:
> It's not fully clear to me whether this part is still correct. My 
> understanding is that if we use `el_wset` to set the getchar callback, we 
> should always use wchar_t, regardless of libedit version. This is only true 
> if all wide-char capable libedit versions also define EL_CLIENTDATA.
> 
> Is this the case?
I believe that you are correct: If you use el_wset, you should use wchar_t. The 
problem is that for libedit versions prior to 2016-04-19 the getchar function 
used char * for narrow and wchar_t * for wide. Versions after that use wchar_t 
* for both. This was an accident due to some code refactoring. If you are 
checking if that's the case or not, perhaps you can determine this if 
el_rfunc_t is defined in histedit.h or not. Unfortunately there is no compile 
time way to determine if that's the case or not.


https://reviews.llvm.org/D47625



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

[Lldb-commits] [lldb] r333777 - Add dependency on clang-headers when building LLDB.framework using CMake

2018-06-01 Thread Alex Langford via lldb-commits 
Author: xiaobai
Date: Fri Jun  1 11:14:49 2018
New Revision: 333777

URL: http://llvm.org/viewvc/llvm-project?rev=333777&view=rev
Log:
Add dependency on clang-headers when building LLDB.framework using CMake

Summary:
The LLDB.framework generated when building with CMake + Ninja/Make is
completely missing the clang headers. Although the code to copy them exists, we
don't even generate them unless we're building LLDB standalone.

Reviewers: clayborg, labath, sas

Subscribers: mgorny, lldb-commits

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

Modified:
lldb/trunk/source/API/CMakeLists.txt

Modified: lldb/trunk/source/API/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/API/CMakeLists.txt?rev=333777&r1=333776&r2=333777&view=diff
==
--- lldb/trunk/source/API/CMakeLists.txt (original)
+++ lldb/trunk/source/API/CMakeLists.txt Fri Jun  1 11:14:49 2018
@@ -187,6 +187,9 @@ if(LLDB_BUILD_FRAMEWORK)
 PUBLIC_HEADER "${framework_headers}")
 
   if(NOT IOS)
+if (NOT LLDB_BUILT_STANDALONE)
+  add_dependencies(liblldb clang-headers)
+endif()
 add_custom_command(TARGET liblldb POST_BUILD
   COMMAND ${CMAKE_COMMAND} -E copy_directory 
${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders $/Headers
   COMMAND ${CMAKE_COMMAND} -E create_symlink Versions/Current/Headers 
${CMAKE_BINARY_DIR}/${LLDB_FRAMEWORK_INSTALL_DIR}/LLDB.framework/Headers


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

[Lldb-commits] [PATCH] D47612: Add dependency on clang-headers when building LLDB.framework using CMake

2018-06-01 Thread Alex Langford via Phabricator via lldb-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rL333777: Add dependency on clang-headers when building 
LLDB.framework using CMake (authored by xiaobai, committed by ).
Herald added a subscriber: llvm-commits.

Repository:
  rL LLVM

https://reviews.llvm.org/D47612

Files:
  lldb/trunk/source/API/CMakeLists.txt


Index: lldb/trunk/source/API/CMakeLists.txt
===
--- lldb/trunk/source/API/CMakeLists.txt
+++ lldb/trunk/source/API/CMakeLists.txt
@@ -187,6 +187,9 @@
 PUBLIC_HEADER "${framework_headers}")
 
   if(NOT IOS)
+if (NOT LLDB_BUILT_STANDALONE)
+  add_dependencies(liblldb clang-headers)
+endif()
 add_custom_command(TARGET liblldb POST_BUILD
   COMMAND ${CMAKE_COMMAND} -E copy_directory 
${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders $/Headers
   COMMAND ${CMAKE_COMMAND} -E create_symlink Versions/Current/Headers 
${CMAKE_BINARY_DIR}/${LLDB_FRAMEWORK_INSTALL_DIR}/LLDB.framework/Headers


Index: lldb/trunk/source/API/CMakeLists.txt
===
--- lldb/trunk/source/API/CMakeLists.txt
+++ lldb/trunk/source/API/CMakeLists.txt
@@ -187,6 +187,9 @@
 PUBLIC_HEADER "${framework_headers}")
 
   if(NOT IOS)
+if (NOT LLDB_BUILT_STANDALONE)
+  add_dependencies(liblldb clang-headers)
+endif()
 add_custom_command(TARGET liblldb POST_BUILD
   COMMAND ${CMAKE_COMMAND} -E copy_directory ${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders $/Headers
   COMMAND ${CMAKE_COMMAND} -E create_symlink Versions/Current/Headers ${CMAKE_BINARY_DIR}/${LLDB_FRAMEWORK_INSTALL_DIR}/LLDB.framework/Headers
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D47612: Add dependency on clang-headers when building LLDB.framework using CMake

2018-06-01 Thread Alex Langford via Phabricator via lldb-commits 
xiaobai added a comment.

In https://reviews.llvm.org/D47612#1118615, @labath wrote:

> I don't understand the interactions between lldb framework and clang headers, 
> but if there isn't a better person to review this, I'm happy to rubber-stamp 
> it. :)


Thanks! I don't quite understand it either, but I am trying to make it so we 
can build the LLDB framework with just CMake. :)


Repository:
  rL LLVM

https://reviews.llvm.org/D47612



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

Re: [Lldb-commits] [lldb] r333700 - [IRMemoryMap] Test interleaved Mallocs and Frees

2018-06-01 Thread Vedant Kumar via lldb-commits 


> On Jun 1, 2018, at 1:39 AM, Pavel Labath  wrote:
> 
> On Thu, 31 May 2018 at 23:13, Vedant Kumar via lldb-commits
>  wrote:
>> 
>> Author: vedantk
>> Date: Thu May 31 15:09:01 2018
>> New Revision: 333700
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=333700&view=rev
>> Log:
>> [IRMemoryMap] Test interleaved Mallocs and Frees
>> 
>> This adds a new command to the ir-memory-map tester:
>> 
>>  free 
>> 
>> The argument to free is an index which identifies which live allocation
>> to free. Index 0 identifies the first live allocation in the address
>> space, index 1 identifies the second, etc. where the allocations are
>> sorted in increasing order.
>> 
>> For illustrative purposes, assume malloc returns monotonically
>> increasing addresses. Here are some examples of how free would work:
>> 
>> Example 1
>> -
>> 
>> malloc 16 1
>> malloc 32 1
>> free 1  //< Free the 32-byte allocation.
>> free 0  //< Next, free the 16-byte allocation.
> 
> I think it would be better if the mallocs and frees were connected
> symbolically instead of by an index that changes after every free. In
> the long test case you add here it's pretty much impossible to figure
> out which allocation a particular free refers to.
> 
> Maybe we could
> attach an optional "label" to each malloc statement and then have
> "free" reference those? e.g. something like:
> LARGEALLOC: malloc 4096 16
> malloc 10, 1 # I won't free this, no label necessary
> free LARGEALLOC # frees first allocation
> 
> Adding parsing code for the extended syntax shouldn't be much work,
> but I believe it will help a lot with the readability of these test
> cases.
> 
> WDYT?

I think this would be a good forward-looking change to make. Maybe it'll help 
test other parts of the API: we have no testing for WriteMemory, or for what 
happens on a double-free.

As an aside, for this particular test case, I'm not sure there's a reason to 
figure out which allocation a free refers to. It might actually be sufficient 
to have the free command pick a random allocation to release (i.e, no 
arguments).

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

Re: [Lldb-commits] [lldb] r333700 - [IRMemoryMap] Test interleaved Mallocs and Frees

2018-06-01 Thread Vedant Kumar via lldb-commits 
Patch up for review: https://reviews.llvm.org/D47646 


thanks,
vedant

> On Jun 1, 2018, at 11:31 AM, Vedant Kumar  wrote:
> 
> 
> 
>> On Jun 1, 2018, at 1:39 AM, Pavel Labath  wrote:
>> 
>> On Thu, 31 May 2018 at 23:13, Vedant Kumar via lldb-commits
>>  wrote:
>>> 
>>> Author: vedantk
>>> Date: Thu May 31 15:09:01 2018
>>> New Revision: 333700
>>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=333700&view=rev
>>> Log:
>>> [IRMemoryMap] Test interleaved Mallocs and Frees
>>> 
>>> This adds a new command to the ir-memory-map tester:
>>> 
>>> free 
>>> 
>>> The argument to free is an index which identifies which live allocation
>>> to free. Index 0 identifies the first live allocation in the address
>>> space, index 1 identifies the second, etc. where the allocations are
>>> sorted in increasing order.
>>> 
>>> For illustrative purposes, assume malloc returns monotonically
>>> increasing addresses. Here are some examples of how free would work:
>>> 
>>> Example 1
>>> -
>>> 
>>> malloc 16 1
>>> malloc 32 1
>>> free 1  //< Free the 32-byte allocation.
>>> free 0  //< Next, free the 16-byte allocation.
>> 
>> I think it would be better if the mallocs and frees were connected
>> symbolically instead of by an index that changes after every free. In
>> the long test case you add here it's pretty much impossible to figure
>> out which allocation a particular free refers to.
>> 
>> Maybe we could
>> attach an optional "label" to each malloc statement and then have
>> "free" reference those? e.g. something like:
>> LARGEALLOC: malloc 4096 16
>> malloc 10, 1 # I won't free this, no label necessary
>> free LARGEALLOC # frees first allocation
>> 
>> Adding parsing code for the extended syntax shouldn't be much work,
>> but I believe it will help a lot with the readability of these test
>> cases.
>> 
>> WDYT?
> 
> I think this would be a good forward-looking change to make. Maybe it'll help 
> test other parts of the API: we have no testing for WriteMemory, or for what 
> happens on a double-free.
> 
> As an aside, for this particular test case, I'm not sure there's a reason to 
> figure out which allocation a free refers to. It might actually be sufficient 
> to have the free command pick a random allocation to release (i.e, no 
> arguments).
> 
> vedant

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

[Lldb-commits] [PATCH] D47646: [IRMemoryMap] Use labels in the "malloc" and "free" lldb-test commands

2018-06-01 Thread Vedant Kumar via Phabricator via lldb-commits 
vsk created this revision.
vsk added a reviewer: labath.

Change the syntax of the malloc and free commands in lldb-test's
ir-memory-map subcommand to:

   ::=  = malloc  
  
   ::= free 

This should make it easier to read and extend tests in the future, e.g
to test IRMemoryMap::WriteMemory or double-free behavior.


https://reviews.llvm.org/D47646

Files:
  lit/Expr/Inputs/ir-memory-map-basic
  lit/Expr/Inputs/ir-memory-map-mix-malloc-free
  lit/Expr/Inputs/ir-memory-map-overlap1
  tools/lldb-test/lldb-test.cpp

Index: tools/lldb-test/lldb-test.cpp
===
--- tools/lldb-test/lldb-test.cpp
+++ tools/lldb-test/lldb-test.cpp
@@ -167,13 +167,25 @@
 cl::init(false), cl::sub(IRMemoryMapSubcommand));
 
 using AllocationT = std::pair;
-bool areAllocationsOverlapping(const AllocationT &L, const AllocationT &R);
 using AddrIntervalMap =
   IntervalMap>;
-bool evalMalloc(IRMemoryMap &IRMemMap, StringRef Line,
-AddrIntervalMap &AllocatedIntervals);
-bool evalFree(IRMemoryMap &IRMemMap, StringRef Line,
-  AddrIntervalMap &AllocatedIntervals);
+
+struct IRMemoryMapTestState {
+  TargetSP Target;
+  IRMemoryMap Map;
+
+  AddrIntervalMap::Allocator IntervalMapAllocator;
+  AddrIntervalMap Allocations;
+
+  StringMap Label2AddrMap;
+
+  IRMemoryMapTestState(TargetSP Target)
+  : Target(Target), Map(Target), Allocations(IntervalMapAllocator) {}
+};
+
+bool areAllocationsOverlapping(const AllocationT &L, const AllocationT &R);
+bool evalMalloc(StringRef Line, IRMemoryMapTestState &State);
+bool evalFree(StringRef Line, IRMemoryMapTestState &State);
 int evaluateMemoryMapCommands(Debugger &Dbg);
 } // namespace irmemorymap
 
@@ -514,17 +526,23 @@
   return R.first < L.second && L.first < R.second;
 }
 
-bool opts::irmemorymap::evalMalloc(IRMemoryMap &IRMemMap, StringRef Line,
-   AddrIntervalMap &AllocatedIntervals) {
-  // ::= malloc  
+bool opts::irmemorymap::evalMalloc(StringRef Line,
+   IRMemoryMapTestState &State) {
+  // ::=  = malloc  
+  StringRef Label;
+  std::tie(Label, Line) = Line.split('=');
+  if (Line.empty())
+return false;
+  Label = Label.trim();
+  Line = Line.trim();
   size_t Size;
   uint8_t Alignment;
   int Matches = sscanf(Line.data(), "malloc %zu %hhu", &Size, &Alignment);
   if (Matches != 2)
 return false;
 
-  outs() << formatv("Command: malloc(size={0}, alignment={1})\n", Size,
-Alignment);
+  outs() << formatv("Command: {0} = malloc(size={1}, alignment={2})\n", Label,
+Size, Alignment);
   if (!isPowerOf2_32(Alignment)) {
 outs() << "Malloc error: alignment is not a power of 2\n";
 exit(1);
@@ -539,7 +557,7 @@
   const bool ZeroMemory = false;
   Status ST;
   addr_t Addr =
-  IRMemMap.Malloc(Size, Alignment, Permissions, AP, ZeroMemory, ST);
+  State.Map.Malloc(Size, Alignment, Permissions, AP, ZeroMemory, ST);
   if (ST.Fail()) {
 outs() << formatv("Malloc error: {0}\n", ST);
 return true;
@@ -557,10 +575,10 @@
   // Check that the allocation does not overlap another allocation. Do so by
   // testing each allocation which may cover the interval [Addr, EndOfRegion).
   addr_t EndOfRegion = Addr + Size;
-  auto Probe = AllocatedIntervals.begin();
+  auto Probe = State.Allocations.begin();
   Probe.advanceTo(Addr); //< First interval s.t stop >= Addr.
   AllocationT NewAllocation = {Addr, EndOfRegion};
-  while (Probe != AllocatedIntervals.end() && Probe.start() < EndOfRegion) {
+  while (Probe != State.Allocations.end() && Probe.start() < EndOfRegion) {
 AllocationT ProbeAllocation = {Probe.start(), Probe.stop()};
 if (areAllocationsOverlapping(ProbeAllocation, NewAllocation)) {
   outs() << "Malloc error: overlapping allocation detected"
@@ -575,41 +593,42 @@
   // to inhibit interval coalescing.
   static unsigned AllocationID = 0;
   if (Size)
-AllocatedIntervals.insert(Addr, EndOfRegion, AllocationID++);
+State.Allocations.insert(Addr, EndOfRegion, AllocationID++);
+
+  // Store the label -> address mapping.
+  State.Label2AddrMap[Label] = Addr;
 
   return true;
 }
 
-bool opts::irmemorymap::evalFree(IRMemoryMap &IRMemMap, StringRef Line,
- AddrIntervalMap &AllocatedIntervals) {
-  // ::= free 
-  size_t AllocIndex;
-  int Matches = sscanf(Line.data(), "free %zu", &AllocIndex);
-  if (Matches != 1)
+bool opts::irmemorymap::evalFree(StringRef Line, IRMemoryMapTestState &State) {
+  // ::= free 
+  if (!Line.startswith("free"))
 return false;
+  StringRef Label = Line.substr(Line.find(' ')).trim();
 
-  outs() << formatv("Command: free(allocation-index={0})\n", AllocIndex);
-
-  // Find and free the AllocIndex-th allocation.
-  auto Probe = AllocatedIntervals.begin();
-  for (size_t I = 0; I < AllocIndex && Probe != AllocatedIntervals.end(); ++I)
-++Probe;
-
-  if (Probe == AllocatedIntervals.end

[Lldb-commits] [PATCH] D47646: [IRMemoryMap] Use labels in the "malloc" and "free" lldb-test commands

2018-06-01 Thread Stella Stamenova via Phabricator via lldb-commits 
stella.stamenova added a comment.

While you are at it, can you make sure this works on Windows? The current 
version of the test that is checked in fails.


https://reviews.llvm.org/D47646



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

[Lldb-commits] [lldb] r333781 - [lldb, process] Fix occasional hang when launching a process in LLDB

2018-06-01 Thread Stella Stamenova via lldb-commits 
Author: stella.stamenova
Date: Fri Jun  1 12:14:53 2018
New Revision: 333781

URL: http://llvm.org/viewvc/llvm-project?rev=333781&view=rev
Log:
[lldb, process] Fix occasional hang when launching a process in LLDB

Summary:
Occasionally, when launching a process in lldb (especially on windows, but not 
limited to), lldb will hang before the process is launched and it will never 
recover. This happens because the timing of the processing of the state changes 
can be slightly different. The state changes that are issued are:

1) SetPublicState(eStateLaunching)
2) SetPrivateState(eStateLaunching)
3) SetPublicState(eStateStopped)
4) SetPrivateState(eStateStopped)

What we expect to see is:
public state: launching -> launching -> stopped
private state: launching -> stopped

What we see is:
public state: launching -> stopped -> launching
private state: launching -> stopped

The second launching change to the public state is issued when 
WaitForProcessStopPrivate calls HandlePrivateEvent on the event which was 
created when the private state was set to launching. HandlePrivateEvent has 
logic to determine whether to broadcase the event and a launching event is 
*always* broadcast. At the same time, when the stopped event is processed by 
WaitForProcessStopPrivate next, the function exists and that event is never 
broadcast, so the public state remains as launching.

HandlePrivateEvent does two things: determine whether there's a next action as 
well as determine whether to broadcast the event that was processed. There's 
only ever a next action set if we are trying to attach to a process, but 
WaitForProcessStopPrivate is only ever called when we are launching a process 
or connecting remotely, so the first part of HandlePrivateEvent (handling the 
next action) is irrelevant for WaitForProcessStopPrivate. As far as 
broadcasting the event is concerned, since we are handling state changes that 
already occurred to the public state (and are now duplicated in the private 
state), I believe the broadcast step is unnecessary also (and in fact, it 
causes the hang).

This change removes the call to HandlePrivateEvent from inside 
WaitForProcessStopPrivate.

Incidentally, there was also a bug filed recently that is the same issue: 
https://bugs.llvm.org/show_bug.cgi?id=37496

Reviewers: asmith, labath, zturner, jingham

Reviewed By: zturner, jingham

Subscribers: llvm-commits

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

Modified:
lldb/trunk/include/lldb/lldb-enumerations.h
lldb/trunk/source/Plugins/Process/Windows/Common/ProcessWindows.cpp
lldb/trunk/source/Target/Process.cpp

Modified: lldb/trunk/include/lldb/lldb-enumerations.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/lldb-enumerations.h?rev=333781&r1=333780&r2=333781&view=diff
==
--- lldb/trunk/include/lldb/lldb-enumerations.h (original)
+++ lldb/trunk/include/lldb/lldb-enumerations.h Fri Jun  1 12:14:53 2018
@@ -44,6 +44,9 @@ enum StateType {
///launched or attached to anything yet
   eStateAttaching, ///< Process is currently trying to attach
   eStateLaunching, ///< Process is in the process of launching
+  // The state changes eStateAttaching and eStateLaunching are both sent while 
the
+  // private state thread is either not yet started or paused. For that 
reason, they
+  // should only be signaled as public state changes, and not private state 
changes.
   eStateStopped,   ///< Process or thread is stopped and can be examined.
   eStateRunning,   ///< Process or thread is running and can't be examined.
   eStateStepping,  ///< Process or thread is in the process of stepping and can

Modified: lldb/trunk/source/Plugins/Process/Windows/Common/ProcessWindows.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/Windows/Common/ProcessWindows.cpp?rev=333781&r1=333780&r2=333781&view=diff
==
--- lldb/trunk/source/Plugins/Process/Windows/Common/ProcessWindows.cpp 
(original)
+++ lldb/trunk/source/Plugins/Process/Windows/Common/ProcessWindows.cpp Fri Jun 
 1 12:14:53 2018
@@ -249,7 +249,6 @@ Status ProcessWindows::DoLaunch(Module *
   bool stop_at_entry = launch_info.GetFlags().Test(eLaunchFlagStopAtEntry);
   m_session_data.reset(new ProcessWindowsData(stop_at_entry));
 
-  SetPrivateState(eStateLaunching);
   DebugDelegateSP delegate(new LocalDebugDelegate(shared_from_this()));
   m_session_data->m_debugger.reset(new DebuggerThread(delegate));
   DebuggerThreadSP debugger = m_session_data->m_debugger;

Modified: lldb/trunk/source/Target/Process.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/Process.cpp?rev=333781&r1=333780&r2=333781&view=diff
==
--- lldb/trunk/source/Target/Process.cpp (original)
+++ lldb/trunk/source/Target/P

[Lldb-commits] [PATCH] D47646: [IRMemoryMap] Use labels in the "malloc" and "free" lldb-test commands

2018-06-01 Thread Vedant Kumar via Phabricator via lldb-commits 
vsk added a comment.

In https://reviews.llvm.org/D47646#1119396, @stella.stamenova wrote:

> While you are at it, can you make sure this works on Windows? The current 
> version of the test that is checked in fails.


Sorry about that. Could you point me to the error message?


https://reviews.llvm.org/D47646



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

[Lldb-commits] [PATCH] D47646: [IRMemoryMap] Use labels in the "malloc" and "free" lldb-test commands

2018-06-01 Thread Stella Stamenova via Phabricator via lldb-commits 
stella.stamenova added a comment.

In https://reviews.llvm.org/D47646#1119471, @vsk wrote:

> In https://reviews.llvm.org/D47646#1119396, @stella.stamenova wrote:
>
> > While you are at it, can you make sure this works on Windows? The current 
> > version of the test that is checked in fails.
>
>
> Sorry about that. Could you point me to the error message?


"Cannot use process to test IRMemoryMap"


https://reviews.llvm.org/D47646



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

[Lldb-commits] [PATCH] D47646: [IRMemoryMap] Use labels in the "malloc" and "free" lldb-test commands

2018-06-01 Thread Vedant Kumar via Phabricator via lldb-commits 
vsk added a comment.

In https://reviews.llvm.org/D47646#1119479, @stella.stamenova wrote:

> In https://reviews.llvm.org/D47646#1119471, @vsk wrote:
>
> > In https://reviews.llvm.org/D47646#1119396, @stella.stamenova wrote:
> >
> > > While you are at it, can you make sure this works on Windows? The current 
> > > version of the test that is checked in fails.
> >
> >
> > Sorry about that. Could you point me to the error message?
>
>
> "Cannot use process to test IRMemoryMap"


Hm, I'm afraid this just tells us that the debugger either failed to create a 
process, or that the process is not alive / incapable of JIT'ing. As I don't 
have a Windows machine on hand, I can't dig into this further. Would you mind 
taking a look? I can simply disable these tests on Windows for now.


https://reviews.llvm.org/D47646



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

[Lldb-commits] [PATCH] D47646: [IRMemoryMap] Use labels in the "malloc" and "free" lldb-test commands

2018-06-01 Thread Vedant Kumar via Phabricator via lldb-commits 
vsk added a comment.

In https://reviews.llvm.org/D47646#1119487, @vsk wrote:

> In https://reviews.llvm.org/D47646#1119479, @stella.stamenova wrote:
>
> > In https://reviews.llvm.org/D47646#1119471, @vsk wrote:
> >
> > > In https://reviews.llvm.org/D47646#1119396, @stella.stamenova wrote:
> > >
> > > > While you are at it, can you make sure this works on Windows? The 
> > > > current version of the test that is checked in fails.
> > >
> > >
> > > Sorry about that. Could you point me to the error message?
> >
> >
> > "Cannot use process to test IRMemoryMap"
>
>
> Hm, I'm afraid this just tells us that the debugger either failed to create a 
> process, or that the process is not alive / incapable of JIT'ing. As I don't 
> have a Windows machine on hand, I can't dig into this further. Would you mind 
> taking a look? I can simply disable these tests on Windows for now.


One additional thing to try: you can run the lldb-test command with `-log 
path/to/log/file` appended. The resulting logging output may help narrow down 
the process creation issue.


https://reviews.llvm.org/D47646



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

[Lldb-commits] [lldb] r333785 - Disable TestIRMemoryMap.test on Windows

2018-06-01 Thread Vedant Kumar via lldb-commits 
Author: vedantk
Date: Fri Jun  1 13:02:57 2018
New Revision: 333785

URL: http://llvm.org/viewvc/llvm-project?rev=333785&view=rev
Log:
Disable TestIRMemoryMap.test on Windows

It's been pointed out in https://reviews.llvm.org/D47646 that lldb-test
fails to create a usable process on Windows when running this test.

Modified:
lldb/trunk/lit/Expr/TestIRMemoryMap.test

Modified: lldb/trunk/lit/Expr/TestIRMemoryMap.test
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Expr/TestIRMemoryMap.test?rev=333785&r1=333784&r2=333785&view=diff
==
--- lldb/trunk/lit/Expr/TestIRMemoryMap.test (original)
+++ lldb/trunk/lit/Expr/TestIRMemoryMap.test Fri Jun  1 13:02:57 2018
@@ -1,3 +1,5 @@
+# REQUIRES: nowindows
+
 # RUN: %cxx %p/Inputs/call-function.cpp -g -o %t
 
 # RUN: lldb-test ir-memory-map %t %S/Inputs/ir-memory-map-basic


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

[Lldb-commits] [lldb] r333786 - Fix Module::FindTypes to return the correct number of matches.

2018-06-01 Thread Frederic Riss via lldb-commits 
Author: friss
Date: Fri Jun  1 13:14:21 2018
New Revision: 333786

URL: http://llvm.org/viewvc/llvm-project?rev=333786&view=rev
Log:
Fix Module::FindTypes to return the correct number of matches.

In r331719, I changed Module::FindTypes not to limit the amount
of types returned by the Symbol provider, because we want all
possible matches to be able to filter them. In one code path,
the filtering was applied to the TypeList without changing the
number of types that gets returned. This is turn could cause
consumers to access beyond the end of the TypeList.

This patch fixes this case and also adds an assertion to
TypeList::GetTypeAtIndex to catch those obvious programming
mistakes.

Triggering the condition in which we performed the incorrect
access was not easy. It happened a lot in mixed Swift/ObjectiveC
code, but I was able to trigger it in pure Objective C++ although
in a contrieved way.

rdar://problem/40254997

Added:
lldb/trunk/packages/Python/lldbsuite/test/lang/objcxx/class-name-clash/

lldb/trunk/packages/Python/lldbsuite/test/lang/objcxx/class-name-clash/Makefile

lldb/trunk/packages/Python/lldbsuite/test/lang/objcxx/class-name-clash/TestNameClash.py

lldb/trunk/packages/Python/lldbsuite/test/lang/objcxx/class-name-clash/main.mm

lldb/trunk/packages/Python/lldbsuite/test/lang/objcxx/class-name-clash/myobject.mm
Modified:
lldb/trunk/source/Core/Module.cpp
lldb/trunk/source/Symbol/TypeList.cpp

Added: 
lldb/trunk/packages/Python/lldbsuite/test/lang/objcxx/class-name-clash/Makefile
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/objcxx/class-name-clash/Makefile?rev=333786&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/lang/objcxx/class-name-clash/Makefile 
(added)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/lang/objcxx/class-name-clash/Makefile 
Fri Jun  1 13:14:21 2018
@@ -0,0 +1,7 @@
+LEVEL = ../../../make
+OBJCXX_SOURCES := main.mm myobject.mm
+include $(LEVEL)/Makefile.rules
+
+# myobject.o needs to be built without debug info
+myobject.o: myobject.mm
+   $(CXX) -c -o $@ $<

Added: 
lldb/trunk/packages/Python/lldbsuite/test/lang/objcxx/class-name-clash/TestNameClash.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/objcxx/class-name-clash/TestNameClash.py?rev=333786&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/lang/objcxx/class-name-clash/TestNameClash.py
 (added)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/lang/objcxx/class-name-clash/TestNameClash.py
 Fri Jun  1 13:14:21 2018
@@ -0,0 +1,6 @@
+from lldbsuite.test import decorators
+from lldbsuite.test import lldbinline
+
+lldbinline.MakeInlineTest(
+__file__, globals(), [
+decorators.skipIfFreeBSD, decorators.skipIfLinux, 
decorators.skipIfWindows])

Added: 
lldb/trunk/packages/Python/lldbsuite/test/lang/objcxx/class-name-clash/main.mm
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/objcxx/class-name-clash/main.mm?rev=333786&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/lang/objcxx/class-name-clash/main.mm 
(added)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/lang/objcxx/class-name-clash/main.mm 
Fri Jun  1 13:14:21 2018
@@ -0,0 +1,21 @@
+#import 
+
+namespace NS {
+  class MyObject { int i = 42; };
+  NS::MyObject globalObject;
+}
+
+@interface MyObject: NSObject
+@end
+
+int main ()
+{
+  @autoreleasepool
+  {
+MyObject *o = [MyObject alloc];
+return 0; //% self.expect("fr var o", DATA_TYPES_DISPLAYED_CORRECTLY, 
substrs = ["(MyObject"]);
+  //% self.expect("fr var globalObject", 
DATA_TYPES_DISPLAYED_CORRECTLY, substrs = ["42"]);
+  }
+}
+
+

Added: 
lldb/trunk/packages/Python/lldbsuite/test/lang/objcxx/class-name-clash/myobject.mm
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/objcxx/class-name-clash/myobject.mm?rev=333786&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/lang/objcxx/class-name-clash/myobject.mm
 (added)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/lang/objcxx/class-name-clash/myobject.mm
 Fri Jun  1 13:14:21 2018
@@ -0,0 +1,7 @@
+#import 
+
+@interface MyObject : NSObject
+@end
+
+@implementation MyObject
+@end

Modified: lldb/trunk/source/Core/Module.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/Module.cpp?rev=333786&r1=333785&r2=333786&view=diff
==
--- lldb/trunk/source/Core/Module.cpp (original)
+++ lldb/trunk/source/Core/Module.cpp Fri Jun  1 13:14:21 2018
@@ -1030,6 +1030,7 @@ size_t Module::FindTypes(
 std::string name_str(name.

[Lldb-commits] [PATCH] D47646: [IRMemoryMap] Use labels in the "malloc" and "free" lldb-test commands

2018-06-01 Thread Stella Stamenova via Phabricator via lldb-commits 
stella.stamenova added a comment.

I can look into the failure - but can you XFAIL the test rather than skipping 
it and log a bug, so that we can track the failure rather than potentially 
assuming down the line that the test is not meant for windows?


https://reviews.llvm.org/D47646



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

[Lldb-commits] [lldb] r333787 - XFAIL TestIRMemoryMap.test on Windows

2018-06-01 Thread Vedant Kumar via lldb-commits 
Author: vedantk
Date: Fri Jun  1 13:32:32 2018
New Revision: 333787

URL: http://llvm.org/viewvc/llvm-project?rev=333787&view=rev
Log:
XFAIL TestIRMemoryMap.test on Windows

I've xfailed this test instead of skipping it by request
(https://reviews.llvm.org/D47646).

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

Modified:
lldb/trunk/lit/Expr/TestIRMemoryMap.test

Modified: lldb/trunk/lit/Expr/TestIRMemoryMap.test
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Expr/TestIRMemoryMap.test?rev=333787&r1=333786&r2=333787&view=diff
==
--- lldb/trunk/lit/Expr/TestIRMemoryMap.test (original)
+++ lldb/trunk/lit/Expr/TestIRMemoryMap.test Fri Jun  1 13:32:32 2018
@@ -1,4 +1,4 @@
-# REQUIRES: nowindows
+# XFAIL: windows
 
 # RUN: %cxx %p/Inputs/call-function.cpp -g -o %t
 


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

[Lldb-commits] [PATCH] D47646: [IRMemoryMap] Use labels in the "malloc" and "free" lldb-test commands

2018-06-01 Thread Vedant Kumar via Phabricator via lldb-commits 
vsk added a comment.

In https://reviews.llvm.org/D47646#1119512, @stella.stamenova wrote:

> I can look into the failure - but can you XFAIL the test rather than skipping 
> it and log a bug, so that we can track the failure rather than potentially 
> assuming down the line that the test is not meant for windows?


Sure, I've xfailed the test in r333787 and filed llvm.org/PR37656.


https://reviews.llvm.org/D47646



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

[Lldb-commits] [lldb] r333789 - [lit, lldbmi] Skip the new break-insert test on Windows

2018-06-01 Thread Stella Stamenova via lldb-commits 
Author: stella.stamenova
Date: Fri Jun  1 14:29:43 2018
New Revision: 333789

URL: http://llvm.org/viewvc/llvm-project?rev=333789&view=rev
Log:
[lit, lldbmi] Skip the new break-insert test on Windows

Summary: Skip the new break-insert test on Windows because it hangs and so the 
test suite never completes. All other lldb-mi tests in the test suite are also 
skipped on windows

Reviewers: asmith, aprantl, polyakov.alex

Reviewed By: aprantl

Subscribers: ki.stfu, llvm-commits

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

Modified:
lldb/trunk/lit/tools/lldb-mi/breakpoint/break-insert.test

Modified: lldb/trunk/lit/tools/lldb-mi/breakpoint/break-insert.test
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/tools/lldb-mi/breakpoint/break-insert.test?rev=333789&r1=333788&r2=333789&view=diff
==
--- lldb/trunk/lit/tools/lldb-mi/breakpoint/break-insert.test (original)
+++ lldb/trunk/lit/tools/lldb-mi/breakpoint/break-insert.test Fri Jun  1 
14:29:43 2018
@@ -1,3 +1,7 @@
+# REQUIRES: nowindows
+# -> llvm.org/pr24452
+# Rather than XFAILing the test, skip it on Windows because it hangs
+
 # RUN: %cc %p/inputs/break-insert.c -g
 # RUN: %lldbmi < %s | FileCheck %s
 


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

[Lldb-commits] [lldb] r333790 - [lit, pdb] Fix two failing PDB tests on Windows

2018-06-01 Thread Stella Stamenova via lldb-commits 
Author: stella.stamenova
Date: Fri Jun  1 14:33:27 2018
New Revision: 333790

URL: http://llvm.org/viewvc/llvm-project?rev=333790&view=rev
Log:
[lit, pdb] Fix two failing PDB tests on Windows

Summary: One of the tests is failing to build because it needs GS-, the second 
test does not correctly match all the expected function names because newer DIA 
SDKs annotate the function names with their return type and inputs (e.g. 
"static long `anonymous namespace'::StaticFunction(int)")

Reviewers: asmith, zturner

Reviewed By: zturner

Subscribers: llvm-commits

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

Modified:
lldb/trunk/lit/SymbolFile/PDB/func-symbols.test
lldb/trunk/lit/SymbolFile/PDB/variables.test

Modified: lldb/trunk/lit/SymbolFile/PDB/func-symbols.test
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/SymbolFile/PDB/func-symbols.test?rev=333790&r1=333789&r2=333790&view=diff
==
--- lldb/trunk/lit/SymbolFile/PDB/func-symbols.test (original)
+++ lldb/trunk/lit/SymbolFile/PDB/func-symbols.test Fri Jun  1 14:33:27 2018
@@ -27,6 +27,11 @@ CHECK-DAG: [[TY30:.*]]:   Type{[[UID30:.
 CHECK-DAG: [[TY31:.*]]:   Type{[[UID31:.*]]} , name = "`anonymous 
namespace'::StaticFunction", decl = FuncSymbols.cpp:4, compiler_type = {{.*}} 
long (int)
 CHECK-DAG: [[TY32:.*]]:   Type{[[UID32:.*]]} , name = "InlinedFunction", decl 
= FuncSymbols.cpp:10, compiler_type = {{.*}} int (long)
 
+CHECK: {{.*}}:   CompileUnit{{.*}}, language = "c++", file = 
'{{.*}}\FuncSymbols.cpp'
+CHECK-DAG: Function{[[UID30]]}, mangled = ?FunctionCall@@YAXXZ, demangled = 
{{.*}}, type = [[TY30]]
+CHECK-DAG: Function{[[UID31]]}, demangled = {{.*}}`anonymous 
namespace'::StaticFunction{{.*}}, type = [[TY31]]
+CHECK-DAG: Function{[[UID32]]}, demangled = {{.*}}InlinedFunction{{.*}}, type 
= [[TY32]]
+
 CHECK: {{.*}}:   CompileUnit{{.*}}, language = "c++", file = 
'{{.*}}\FuncSymbolsTestMain.cpp'
 CHECK-DAG: Function{[[UID0]]}, mangled = ?Func_arg_array@@YAHQAH@Z, demangled 
= {{.*}}, type = [[TY0]]
 CHECK-DAG: Function{[[UID1]]}, mangled = ?Func_arg_void@@YAXXZ, demangled = 
{{.*}}, type = [[TY1]]
@@ -34,14 +39,9 @@ CHECK-DAG: Function{[[UID2]]}, mangled =
 CHECK-DAG: Function{[[UID3]]}, mangled = ?Func_varargs@@YAXZZ, demangled = 
{{.*}}, type = [[TY3]]
 CHECK-DAG: Function{[[UID4]]}, mangled = ?Func@NS@@YAXDH@Z, demangled = 
{{.*}}, type = [[TY4]]
 CHECK-DAG: Function{[[UID5]]}, mangled = _main, demangled = {{.*}}, type = 
[[TY5]]
-CHECK-DAG: Function{[[UID6]]}, demangled = `anonymous namespace'::Func, type = 
[[TY6]]
-CHECK-DAG: Function{[[UID7]]}, demangled = StaticFunction, type = [[TY7]]
+CHECK-DAG: Function{[[UID6]]}, demangled = {{.*}}`anonymous 
namespace'::Func{{.*}}, type = [[TY6]]
+CHECK-DAG: Function{[[UID7]]}, demangled = {{.*}}StaticFunction{{.*}}, type = 
[[TY7]]
 CHECK-DAG: Function{[[UID8]]}, mangled = ?Func@A@MemberTest@@QAAHHZZ, 
demangled = {{.*}}, type = [[TY8]]
 CHECK-DAG: Function{[[UID9]]}, mangled = ??$TemplateFunc@$00H@@YAXH@Z, 
demangled = {{.*}}, type = [[TY9]]
 CHECK-DAG: Function{[[UID10]]}, mangled = ??$TemplateFunc@$00HHH@@YAXHHH@Z, 
demangled = {{.*}}, type = [[TY10]]
 CHECK-DAG: Function{[[UID11]]}, mangled = ?InlinedFunction@@YAXJ@Z, demangled 
= {{.*}}, type = [[TY11]]
-
-CHECK: {{.*}}:   CompileUnit{{.*}}, language = "c++", file = 
'{{.*}}\FuncSymbols.cpp'
-CHECK-DAG: Function{[[UID30]]}, mangled = ?FunctionCall@@YAXXZ, demangled = 
{{.*}}, type = [[TY30]]
-CHECK-DAG: Function{[[UID31]]}, demangled = `anonymous 
namespace'::StaticFunction, type = [[TY31]]
-CHECK-DAG: Function{[[UID32]]}, demangled = InlinedFunction, type = [[TY32]]

Modified: lldb/trunk/lit/SymbolFile/PDB/variables.test
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/SymbolFile/PDB/variables.test?rev=333790&r1=333789&r2=333790&view=diff
==
--- lldb/trunk/lit/SymbolFile/PDB/variables.test (original)
+++ lldb/trunk/lit/SymbolFile/PDB/variables.test Fri Jun  1 14:33:27 2018
@@ -1,5 +1,5 @@
 REQUIRES: windows
-RUN: clang-cl /Z7 /c %S/Inputs/VariablesTest.cpp /o %T/VariablesTest.cpp.obj
+RUN: clang-cl /Z7 /c /GS- %S/Inputs/VariablesTest.cpp /o 
%T/VariablesTest.cpp.obj
 RUN: link %T/VariablesTest.cpp.obj /DEBUG /nodefaultlib /ENTRY:main 
/OUT:%T/VariablesTest.cpp.exe
 RUN: lldb-test symbols %T/VariablesTest.cpp.exe | FileCheck %s
 


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

[Lldb-commits] [lldb] r333813 - Fix support for distinguishing archive members by timestamp on Darwin.

2018-06-01 Thread James Y Knight via lldb-commits 
Author: jyknight
Date: Fri Jun  1 19:44:10 2018
New Revision: 333813

URL: http://llvm.org/viewvc/llvm-project?rev=333813&view=rev
Log:
Fix support for distinguishing archive members by timestamp on Darwin.

On Darwin, the binary's symbol table points to debug info in object
files -- potentially object files within a static library. Such a
library may have multiple entries with the same name, distinguished
only by timestamp.

The code was already _attempting_ to handle this case (see the code in
ObjectContainerBSDArchive::Archive::FindObject which disambiguates via
timestamp). But, unfortunately, while the timestamp was taken into
account on the _first_ lookup, the result was then cached in a map
keyed only off of the path.

Added the timestamp to the cache, and added a test case.

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

Added:
lldb/trunk/packages/Python/lldbsuite/test/macosx/duplicate-archive-members/

lldb/trunk/packages/Python/lldbsuite/test/macosx/duplicate-archive-members/Makefile

lldb/trunk/packages/Python/lldbsuite/test/macosx/duplicate-archive-members/TestDuplicateMembers.py

lldb/trunk/packages/Python/lldbsuite/test/macosx/duplicate-archive-members/a.c

lldb/trunk/packages/Python/lldbsuite/test/macosx/duplicate-archive-members/main.c

lldb/trunk/packages/Python/lldbsuite/test/macosx/duplicate-archive-members/sub1/

lldb/trunk/packages/Python/lldbsuite/test/macosx/duplicate-archive-members/sub1/a.c
Modified:
lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h

Added: 
lldb/trunk/packages/Python/lldbsuite/test/macosx/duplicate-archive-members/Makefile
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/macosx/duplicate-archive-members/Makefile?rev=333813&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/macosx/duplicate-archive-members/Makefile
 (added)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/macosx/duplicate-archive-members/Makefile
 Fri Jun  1 19:44:10 2018
@@ -0,0 +1,22 @@
+LEVEL = ../../make
+
+C_SOURCES := main.c
+
+# Make an archive that has two object files with the same name, but
+# different timestamps. Do it all in one rule so that the timestamps
+# can be controlled without confusing Make.
+libfoo.a: a.c sub1/a.c
+   $(CC) $(CFLAGS) -c $(http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/macosx/duplicate-archive-members/TestDuplicateMembers.py?rev=333813&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/macosx/duplicate-archive-members/TestDuplicateMembers.py
 (added)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/macosx/duplicate-archive-members/TestDuplicateMembers.py
 Fri Jun  1 19:44:10 2018
@@ -0,0 +1,62 @@
+"""Test breaking inside functions defined within a BSD archive file 
libfoo.a."""
+
+from __future__ import print_function
+
+
+import os
+import time
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class BSDArchivesTestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def setUp(self):
+# Call super's setUp().
+TestBase.setUp(self)
+# Find the line number in a(int) to break at.
+self.line = line_number(
+'a.c', '// Set file and line breakpoint inside a().')
+
+@expectedFailureAll(
+oslist=["windows"],
+bugnumber="llvm.org/pr24527.  Makefile.rules doesn't know how to build 
static libs on Windows")
+def test(self):
+"""Break inside a() and b() defined within libfoo.a."""
+self.build()
+
+exe = self.getBuildArtifact("a.out")
+self.runCmd("file " + exe, CURRENT_EXECUTABLE_SET)
+
+# Break on a() and b() symbols
+lldbutil.run_break_set_by_symbol(
+self, "a", sym_exact=True)
+lldbutil.run_break_set_by_symbol(
+self, "b", sym_exact=True)
+
+self.runCmd("run", RUN_SUCCEEDED)
+
+# The stop reason of the thread should be breakpoint.
+self.expect("thread list", STOPPED_DUE_TO_BREAKPOINT,
+substrs=['stopped',
+ 'stop reason = breakpoint'])
+
+# Break at a(int) first.
+self.expect("frame variable", VARIABLES_DISPLAYED_CORRECTLY,
+substrs=['(int) arg = 1'])
+self.expect("frame variable __a_global", VARIABLES_DISPLAYED_CORRECTLY,
+substrs=['(int) __a_global = 1'])
+
+# Continue the program, we should break at b(int) next.
+self.runCmd("continue")
+self.expect("thread list", STOPPED_DUE_TO_BREAKPOINT,
+substrs=['stopped',
+ 'stop reason = breakpoint'])
+sel

[Lldb-commits] [lldb] r333816 - Fix silly error introduced after testing in r333813.

2018-06-01 Thread James Y Knight via lldb-commits 
Author: jyknight
Date: Fri Jun  1 21:00:16 2018
New Revision: 333816

URL: http://llvm.org/viewvc/llvm-project?rev=333816&view=rev
Log:
Fix silly error introduced after testing in r333813.

Oops.

Modified:

lldb/trunk/packages/Python/lldbsuite/test/macosx/duplicate-archive-members/TestDuplicateMembers.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/macosx/duplicate-archive-members/TestDuplicateMembers.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/macosx/duplicate-archive-members/TestDuplicateMembers.py?rev=333816&r1=333815&r2=333816&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/macosx/duplicate-archive-members/TestDuplicateMembers.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/macosx/duplicate-archive-members/TestDuplicateMembers.py
 Fri Jun  1 21:00:16 2018
@@ -15,13 +15,6 @@ class BSDArchivesTestCase(TestBase):
 
 mydir = TestBase.compute_mydir(__file__)
 
-def setUp(self):
-# Call super's setUp().
-TestBase.setUp(self)
-# Find the line number in a(int) to break at.
-self.line = line_number(
-'a.c', '// Set file and line breakpoint inside a().')
-
 @expectedFailureAll(
 oslist=["windows"],
 bugnumber="llvm.org/pr24527.  Makefile.rules doesn't know how to build 
static libs on Windows")


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