[Lldb-commits] Buildbot numbers for the last week of 12/3/2017 - 12/9/2017

2017-12-13 Thread Galina Kistanova via lldb-commits 
Hello everyone,

Below are some buildbot numbers for the last week of 12/3/2017 - 12/9/2017.

Please see the same data in attached csv files:

The longest time each builder was red during the week;
"Status change ratio" by active builder (percent of builds that changed the
builder status from greed to red or from red to green);
Count of commits by project;
Number of completed builds, failed builds and average build time for
successful builds per active builder;
Average waiting time for a revision to get build result per active builder
(response time).

Thanks

Galina


The longest time each builder was red during the week:

  buildername  | was_red
---+-
 clang-s390x-linux-multistage  | 77:40:28
 perf-x86_64-penryn-O3-polly-unprofitable  | 58:02:48
 clang-with-thin-lto-windows   | 57:19:47
 clang-x86_64-linux-selfhost-modules-2 | 56:49:12
 clang-x86_64-linux-selfhost-modules   | 56:06:27
 clang-cmake-armv7-a15-full| 33:41:50
 clang-cmake-aarch64-full  | 33:34:05
 clang-cmake-thumbv7-a15-full-sh   | 32:48:17
 clang-x64-ninja-win7  | 31:58:43
 clang-s390x-linux-lnt | 29:33:04
 clang-s390x-linux | 28:24:40
 sanitizer-x86_64-linux-bootstrap-ubsan| 28:11:01
 clang-ppc64be-linux-multistage| 28:07:20
 sanitizer-x86_64-linux-fast   | 27:37:22
 clang-ppc64le-linux   | 27:21:16
 clang-ppc64be-linux   | 27:14:47
 sanitizer-x86_64-linux-bootstrap-msan | 27:12:49
 clang-ppc64le-linux-multistage| 27:12:01
 sanitizer-x86_64-linux-bootstrap  | 27:07:12
 clang-ppc64le-linux-lnt   | 27:02:06
 clang-ppc64be-linux-lnt   | 26:30:54
 openmp-clang-x86_64-linux-debian  | 26:08:14
 clang-x86_64-debian-fast  | 25:41:36
 lld-x86_64-win7   | 22:48:43
 clang-with-lto-ubuntu | 22:45:24
 clang-cmake-aarch64-lld   | 22:08:52
 clang-with-thin-lto-ubuntu| 21:55:03
 clang-cmake-armv7-a15-selfhost-neon   | 21:54:05
 llvm-clang-x86_64-expensive-checks-win| 21:53:32
 clang-lld-x86_64-2stage   | 21:35:04
 clang-cmake-x86_64-avx2-linux | 21:31:56
 clang-cmake-x86_64-avx2-linux-perf| 21:31:31
 clang-cmake-armv7-a15-selfhost| 21:25:25
 sanitizer-x86_64-linux-fuzzer | 21:22:02
 perf-x86_64-penryn-O3-polly-parallel-fast | 20:53:31
 clang-cmake-x86_64-sde-avx512-linux   | 20:50:15
 sanitizer-windows | 19:57:59
 sanitizer-ppc64le-linux   | 17:03:04
 polly-amd64-linux | 16:23:42
 sanitizer-ppc64be-linux   | 16:20:58
 sanitizer-x86_64-linux| 16:06:23
 libcxx-libcxxabi-libunwind-aarch64-linux-noexceptions | 15:49:16
 polly-arm-linux   | 15:29:28
 clang-cmake-aarch64-quick | 14:25:05
 clang-cmake-thumbv7-a15   | 14:23:17
 clang-cmake-armv7-a15 | 14:21:20
 clang-cmake-aarch64-global-isel   | 14:17:21
 clang-bpf-build   | 12:33:12
 sanitizer-x86_64-linux-android| 10:37:46
 lld-x86_64-darwin13   | 05:54:54
 libcxx-libcxxabi-x86_64-linux-debian-noexceptions | 05:26:25
 reverse-iteration | 05:14:53
 clang-cuda-build  | 04:47:30
 clang-atom-d525-fedora-rel| 04:22:35
 lldb-windows7-android | 04:15:37
 ubuntu-gcc7.1-werror  | 03:57:16
 libcxx-libcxxabi-x86_64-linux-debian  | 03:53:19
 lldb-amd64-ninja-netbsd8  | 03:10:33
 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast| 02:53:35
 lldb-x86_64-ubuntu-14.04-buildserver  | 02:41:53
 lldb-x86_64-ubuntu-14.04-cmake| 02:31:01
 lld-x86_64-freebsd| 02:17:59
 lldb-x86-windows-msvc2015 | 02:17:19
 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast  | 01:57:35

[Lldb-commits] Buildbot numbers for the week of 11/26/2017 - 12/02/2017

2017-12-13 Thread Galina Kistanova via lldb-commits 
Hello everyone,

Below are some buildbot numbers for the week of 11/26/2017 - 12/02/2017.

Please see the same data in attached csv files:

The longest time each builder was red during the week;
"Status change ratio" by active builder (percent of builds that changed the
builder status from greed to red or from red to green);
Count of commits by project;
Number of completed builds, failed builds and average build time for
successful builds per active builder;
Average waiting time for a revision to get build result per active builder
(response time).

Thanks

Galina


The longest time each builder was red during the week:

buildername| was_red
---+-
 clang-cuda-build  | 61:24:16
 libcxx-libcxxabi-x86_64-linux-debian-noexceptions | 41:12:57
 lldb-windows7-android | 32:43:26
 clang-x64-ninja-win7  | 32:06:36
 clang-ppc64be-linux-lnt   | 31:39:03
 clang-ppc64be-linux-multistage| 29:13:55
 clang-ppc64be-linux   | 28:11:58
 clang-with-lto-ubuntu | 28:09:40
 sanitizer-ppc64be-linux   | 27:56:11
 ubuntu-gcc7.1-werror  | 27:07:44
 polly-amd64-linux | 25:26:36
 clang-s390x-linux-multistage  | 23:13:18
 polly-arm-linux   | 21:41:21
 clang-cmake-aarch64-lld   | 20:42:04
 clang-with-thin-lto-ubuntu| 19:25:29
 clang-ppc64le-linux-multistage| 14:20:48
 clang-x86_64-linux-abi-test   | 14:06:45
 clang-s390x-linux | 13:42:18
 sanitizer-x86_64-linux-autoconf   | 13:04:48
 openmp-clang-x86_64-linux-debian  | 12:37:31
 openmp-ompt-clang-x86_64-linux-debian | 12:01:16
 clang-cmake-aarch64-global-isel   | 12:01:07
 openmp-gcc-x86_64-linux-debian| 11:49:14
 sanitizer-x86_64-linux| 11:47:20
 clang-cmake-thumbv7-a15-full-sh   | 10:30:29
 sanitizer-x86_64-linux-android| 10:22:47
 sanitizer-x86_64-linux-bootstrap-msan | 10:20:06
 sanitizer-x86_64-linux-bootstrap-ubsan| 10:18:54
 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast  | 10:09:31
 clang-lld-x86_64-2stage   | 10:00:13
 clang-atom-d525-fedora-rel| 09:35:18
 clang-cmake-aarch64-full  | 08:34:44
 sanitizer-x86_64-linux-fast   | 08:26:45
 llvm-mips-linux   | 07:56:36
 llvm-clang-x86_64-expensive-checks-win| 07:40:39
 sanitizer-x86_64-linux-bootstrap  | 07:16:52
 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast| 05:29:37
 clang-cmake-x86_64-avx2-linux-perf| 05:20:59
 clang-cmake-x86_64-avx2-linux | 05:19:55
 clang-ppc64le-linux-lnt   | 05:11:45
 clang-cmake-thumbv7-a15   | 05:10:56
 clang-cmake-x86_64-sde-avx512-linux   | 05:04:39
 clang-cmake-aarch64-quick | 04:53:17
 lld-x86_64-win7   | 04:38:20
 clang-native-arm-lnt  | 04:31:43
 clang-s390x-linux-lnt | 04:05:59
 lldb-x86_64-ubuntu-14.04-buildserver  | 04:01:22
 clang-ppc64le-linux   | 04:00:17
 clang-x86_64-linux-selfhost-modules-2 | 03:56:22
 lldb-amd64-ninja-netbsd8  | 03:45:47
 perf-x86_64-penryn-O3-polly-unprofitable  | 03:34:31
 libcxx-libcxxabi-libunwind-arm-linux-noexceptions | 03:26:24
 libcxx-libcxxabi-libunwind-arm-linux  | 03:25:48
 lld-x86_64-darwin13   | 03:24:02
 clang-x86-windows-msvc2015| 02:47:15
 clang-cmake-armv7-a15-full| 02:36:06
 clang-cmake-armv7-a15 | 02:35:01
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14| 01:57:19
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11| 01:56:45
 clang-x86_64-linux-selfhost-modules   | 01:47:50
 lldb-x86_64-ubuntu-14.04-android  | 01:38:09
 clang-with-thin-lto-windows   | 01:37:00
 reverse-iteration | 01:30:16
 clang-hexagon-elf | 01:26:50
 clang-x86_64-debian-fast  | 01:26:02
 lldb-x86_64-darwin-13.4   | 01:25:19
 lldb-x86-windows-msvc2015 | 01:16:03
 perf-x86_64-penryn-O3-polly-parallel-fast | 01:08:41

Re: [Lldb-commits] [lldb] r320456 - Avoid module import in a textual header, NFC

2017-12-13 Thread Vedant Kumar via lldb-commits 
Ah sorry, didn't see this for a while!

Yes -- I agree on both points here.

vedant

> On Dec 11, 2017, at 9:07 PM, Zachary Turner  wrote:
> 
> Long term it would be nice if we could get all these register definitions 
> automatically generated with llvm-tblgen.  That's a big undertaking, though.
> 
> On Mon, Dec 11, 2017 at 7:27 PM Vedant Kumar via lldb-commits 
> > wrote:
> Author: vedantk
> Date: Mon Dec 11 19:27:13 2017
> New Revision: 320456
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=320456=rev 
> 
> Log:
> Avoid module import in a textual header, NFC
> 
> This unbreaks the lldb modules build (-DLLVM_ENABLE_MODULES=On).
> 
> Modified:
> lldb/trunk/source/Plugins/Process/Utility/RegisterInfos_x86_64.h
> 
> Modified: lldb/trunk/source/Plugins/Process/Utility/RegisterInfos_x86_64.h
> URL: 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/Utility/RegisterInfos_x86_64.h?rev=320456=320455=320456=diff
>  
> 
> ==
> --- lldb/trunk/source/Plugins/Process/Utility/RegisterInfos_x86_64.h 
> (original)
> +++ lldb/trunk/source/Plugins/Process/Utility/RegisterInfos_x86_64.h Mon Dec 
> 11 19:27:13 2017
> @@ -7,11 +7,8 @@
>  //
>  
> //===--===//
> 
> -#include "llvm/Support/Compiler.h"
> -#include 
> -#include 
> -
> -// Project includes
> +// This file is meant to be textually included. Do not #include modular
> +// headers here.
> 
>  // Computes the offset of the given GPR in the user data area.
>  #define GPR_OFFSET(regname) (LLVM_EXTENSION offsetof(GPR, regname))
> 
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits 
> 

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

[Lldb-commits] [PATCH] D41169: ObjectFile: remove ReadSectionData/MemoryMapSectionData mutual recursion

2017-12-13 Thread Greg Clayton via Phabricator via lldb-commits 
clayborg accepted this revision.
clayborg added a comment.

This was left over from before we mmap'ed the entire object file into memory. 
Removing it is fine as the backing DataBufferSP for the object file will be 
mmaped or not depending on where the file was loaded from and if the section 
isn't compressed, we will just hand out a shared slice of the object file data.


https://reviews.llvm.org/D41169



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

Re: [Lldb-commits] [PATCH] D41086: [lldb] Check that a regex is valid before searching by regex for a symbol in a pdb.

2017-12-13 Thread Zachary Turner via lldb-commits 
Can we try using lldb_private::RegularExpression for everything?  (Long
term, adding a new base class method seems like a better approach, but at
least this quick fix is an immediate fix and should be strictly better than
crashing)

On Wed, Dec 13, 2017 at 10:27 AM Aaron Smith via Phabricator <
revi...@reviews.llvm.org> wrote:

> asmith added inline comments.
>
>
> 
> Comment at: source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp:392-399
> +  bool is_regex = false;
> +  if (name_str.find_first_of("[]?*.-+\\") != std::string::npos) {
> +// Trying to compile an invalid regex could throw an exception.
> +// Only search by regex when it's valid.
> +lldb_private::RegularExpression name_regex(name_str);
> +is_regex = name_regex.IsValid();
> +  }
> 
> asmith wrote:
> > zturner wrote:
> > > I can see two possible problems here.
> > >
> > > 1. Now if it is a valid regex, it's going to compile it twice, hurting
> performance (not sure by how much, it could be negligible)
> > >
> > > 2. Whether or not it's valid is determined by asking LLDB's regex
> engine, but it's then compiled with C++ STL's engine.  It's possible they
> won't agree on whether or not a regex is valid.
> > >
> > > You mentioned that it throws an exception on an invalid regex.  What
> actually happens though?  Because we compile with exception support
> disabled.  Does it terminate the program?
> > >
> > > At a minimum, the validity check and the find function should agree on
> the regex engine.  If the only way to make that work is to change from
> `std::regex` to `lldb_private::RegularExpression` as the matching engine,
> then I guess we have to do that.
> > How about this?
> >
> > ```
> >   lldb_private::RegularExpression name_regex(name_str);
> >   if (name_regex.IsValid())
> > FindTypesByRegex(name_regex, max_matches, types); // pass regex here
> >   else
> > FindTypesByName(name_str, max_matches, types);
> >   return types.GetSize();
> > }
> >
> > void SymbolFilePDB::FindTypesByRegex(lldb_private::RegularExpression
> ,
> >  uint32_t max_matches,
> >  lldb_private::TypeMap ) {
> > ```
> Our experience on Windows is that when lldb is built with exceptions
> disabled, std::regex segfaults on an invalid regex causing lldb to
> terminate.
>
> The test case will reproduce the failure or an example from the lldb
> console (if you had the corresponding changes required to do the symbol
> lookup):
>
> image lookup -n function_name
>
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D41086
>
>
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D41092: Enable more abilities in SymbolFilePDB

2017-12-13 Thread Aaron Smith via Phabricator via lldb-commits 
asmith added inline comments.



Comment at: source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp:127
+  }
+  lldbassert(m_session_up.get());
+  if (auto enum_tables_up = m_session_up->getEnumTables()) {

clayborg wrote:
> I am assuming this assert won't fire if we give this an ELF or MachO file or 
> any file that doesn't contain PDB info? Every SymbolFile subclass gets to 
> calculate its abilities on each file until on of them returns that they can 
> handle all abilities, or until all plug-ins have had a chance to answer and 
> then the best one is picked. Seems like this shouldn't be here? I can't 
> remember what checks get run before SymbolFile::CalculateAbilities() is 
> called...
Any ELF or MachO other than PDB or PECOFF will error when calling 
loadDataForEXE or loadDataForPDB and return before reaching the assertion.


Repository:
  rL LLVM

https://reviews.llvm.org/D41092



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

[Lldb-commits] [PATCH] D41086: [lldb] Check that a regex is valid before searching by regex for a symbol in a pdb.

2017-12-13 Thread Aaron Smith via Phabricator via lldb-commits 
asmith added inline comments.



Comment at: source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp:392-399
+  bool is_regex = false;
+  if (name_str.find_first_of("[]?*.-+\\") != std::string::npos) {
+// Trying to compile an invalid regex could throw an exception.
+// Only search by regex when it's valid.
+lldb_private::RegularExpression name_regex(name_str);
+is_regex = name_regex.IsValid();
+  }

asmith wrote:
> zturner wrote:
> > I can see two possible problems here.
> > 
> > 1. Now if it is a valid regex, it's going to compile it twice, hurting 
> > performance (not sure by how much, it could be negligible)
> > 
> > 2. Whether or not it's valid is determined by asking LLDB's regex engine, 
> > but it's then compiled with C++ STL's engine.  It's possible they won't 
> > agree on whether or not a regex is valid.
> > 
> > You mentioned that it throws an exception on an invalid regex.  What 
> > actually happens though?  Because we compile with exception support 
> > disabled.  Does it terminate the program?
> > 
> > At a minimum, the validity check and the find function should agree on the 
> > regex engine.  If the only way to make that work is to change from 
> > `std::regex` to `lldb_private::RegularExpression` as the matching engine, 
> > then I guess we have to do that.
> How about this?
> 
> ```
>   lldb_private::RegularExpression name_regex(name_str);
>   if (name_regex.IsValid())
> FindTypesByRegex(name_regex, max_matches, types); // pass regex here
>   else
> FindTypesByName(name_str, max_matches, types);
>   return types.GetSize();
> }
> 
> void SymbolFilePDB::FindTypesByRegex(lldb_private::RegularExpression ,
>  uint32_t max_matches,
>  lldb_private::TypeMap ) {
> ```
Our experience on Windows is that when lldb is built with exceptions disabled, 
std::regex segfaults on an invalid regex causing lldb to terminate.

The test case will reproduce the failure or an example from the lldb console 
(if you had the corresponding changes required to do the symbol lookup):

image lookup -n function_name


Repository:
  rL LLVM

https://reviews.llvm.org/D41086



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

[Lldb-commits] [PATCH] D41169: ObjectFile: remove ReadSectionData/MemoryMapSectionData mutual recursion

2017-12-13 Thread Davide Italiano via Phabricator via lldb-commits 
davide accepted this revision.
davide added a comment.
This revision is now accepted and ready to land.

LGTM.


https://reviews.llvm.org/D41169



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

[Lldb-commits] [PATCH] D41169: ObjectFile: remove ReadSectionData/MemoryMapSectionData mutual recursion

2017-12-13 Thread Pavel Labath via Phabricator via lldb-commits 
labath created this revision.
labath added a reviewer: clayborg.
Herald added subscribers: JDevlieghere, emaste.

These two functions were calling each other, while handling different
branches of the if(IsInMemory()). I am assuming this had a reason at
some point in the past, but right now it's just confusing.

I resolve this by removing the MemoryMapSectionData function and
inlining the !IsInMemory branch into ReadSectionData. There isn't
anything mmap-related in this function anyway, as the decision whether
to mmap is handled at a higher level.

This is a preparatory step to make ObjectFileELF be able to decompress
compressed sections (I want to make sure that all calls reading section
data are routed through a single piece of code).


https://reviews.llvm.org/D41169

Files:
  include/lldb/Symbol/ObjectFile.h
  source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
  source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
  source/Symbol/ObjectFile.cpp


Index: source/Symbol/ObjectFile.cpp
===
--- source/Symbol/ObjectFile.cpp
+++ source/Symbol/ObjectFile.cpp
@@ -561,20 +561,6 @@
   } else {
 // The object file now contains a full mmap'ed copy of the object file 
data,
 // so just use this
-return MemoryMapSectionData(section, section_data);
-  }
-}
-
-size_t ObjectFile::MemoryMapSectionData(Section *section,
-DataExtractor _data) {
-  // If some other objectfile owns this data, pass this to them.
-  if (section->GetObjectFile() != this)
-return section->GetObjectFile()->MemoryMapSectionData(section,
-  section_data);
-
-  if (IsInMemory()) {
-return ReadSectionData(section, section_data);
-  } else {
 if (!section->IsRelocated())
   RelocateSection(section);
 
Index: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
===
--- source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -444,10 +444,8 @@
 Section *section =
 section_list->FindSectionByName(GetDWARFMachOSegmentName()).get();
 
-// Memory map the DWARF mach-o segment so we have everything mmap'ed
-// to keep our heap memory usage down.
 if (section)
-  m_obj_file->MemoryMapSectionData(section, m_dwarf_data);
+  m_obj_file->ReadSectionData(section, m_dwarf_data);
   }
 
   get_apple_names_data();
Index: source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -1830,8 +1830,6 @@
 }
 
 void ObjectFileELF::CreateSections(SectionList _section_list) {
-  Log *log = lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_MODULES);
-
   if (!m_sections_ap.get() && ParseSectionHeaders()) {
 m_sections_ap.reset(new SectionList());
 
Index: include/lldb/Symbol/ObjectFile.h
===
--- include/lldb/Symbol/ObjectFile.h
+++ include/lldb/Symbol/ObjectFile.h
@@ -805,9 +805,6 @@
   virtual size_t ReadSectionData(Section *section,
  DataExtractor _data);
 
-  size_t MemoryMapSectionData(Section *section,
-  DataExtractor _data);
-
   bool IsInMemory() const { return m_memory_addr != LLDB_INVALID_ADDRESS; }
 
   // Strip linker annotations (such as @@VERSION) from symbol names.


Index: source/Symbol/ObjectFile.cpp
===
--- source/Symbol/ObjectFile.cpp
+++ source/Symbol/ObjectFile.cpp
@@ -561,20 +561,6 @@
   } else {
 // The object file now contains a full mmap'ed copy of the object file data,
 // so just use this
-return MemoryMapSectionData(section, section_data);
-  }
-}
-
-size_t ObjectFile::MemoryMapSectionData(Section *section,
-DataExtractor _data) {
-  // If some other objectfile owns this data, pass this to them.
-  if (section->GetObjectFile() != this)
-return section->GetObjectFile()->MemoryMapSectionData(section,
-  section_data);
-
-  if (IsInMemory()) {
-return ReadSectionData(section, section_data);
-  } else {
 if (!section->IsRelocated())
   RelocateSection(section);
 
Index: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
===
--- source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -444,10 +444,8 @@
 Section *section =
 section_list->FindSectionByName(GetDWARFMachOSegmentName()).get();
 
-// Memory map the DWARF mach-o segment so we have everything mmap'ed
-// to keep our heap memory usage down.
 if (section)
-