[Lldb-commits] [PATCH] D38394: Fix dumping of characters with non-standard sizes

2017-09-29 Thread Petr Pavlu via Phabricator via lldb-commits
petpav01 created this revision.
Herald added subscribers: kristof.beyls, aemerson.

- Prevent dumping of characters in `DumpDataExtractor()` with `item_byte_size` 
bigger than 8 bytes. This case is not supported by the code and results in a 
crash because the code calls `DataExtractor::GetMaxU64Bitfield()` -> 
`GetMaxU64()` that asserts for byte size > 8 bytes.
- Teach `DataExtractor::GetMaxU64()`, `GetMaxU32()` and `GetMaxS64()` how to 
handle byte sizes that are not a multiple of 2. This allows 
`DumpDataExtractor()` to dump characters and booleans with `item_byte_size` in 
the interval of [1, 8] bytes. Values that are not a multiple of 2 would 
previously result in a crash because they were not handled by `GetMaxU64()`.

Examples of two commands that previously resulted in a crash when debugging an 
AArch64 target, and their new behaviour:

  (lldb) register read --format character v0
v0 = error: unsupported byte size (16) for char format
  (lldb) memory read --format boolean --size 7 $sp
  0x7ffd70: false
  0x7ffd77: false
  [...]


https://reviews.llvm.org/D38394

Files:
  include/lldb/Utility/DataExtractor.h
  source/Core/DumpDataExtractor.cpp
  source/Utility/DataExtractor.cpp
  unittests/Core/DataExtractorTest.cpp

Index: unittests/Core/DataExtractorTest.cpp
===
--- unittests/Core/DataExtractorTest.cpp
+++ unittests/Core/DataExtractorTest.cpp
@@ -49,3 +49,86 @@
   EXPECT_EQ(buffer + 4, E.PeekData(4, 0));
   EXPECT_EQ(nullptr, E.PeekData(4, 1));
 }
+
+TEST(DataExtractorTest, GetMaxU64) {
+  uint8_t buffer[] = {0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08};
+  DataExtractor LE(buffer, sizeof(buffer), lldb::eByteOrderLittle,
+   sizeof(void *));
+  DataExtractor BE(buffer, sizeof(buffer), lldb::eByteOrderBig, sizeof(void *));
+
+  lldb::offset_t offset;
+
+  // Check cases at the lower end with the byte size equal to 0 and 1.
+  offset = 0;
+  EXPECT_EQ(0U, LE.GetMaxU64(&offset, 0));
+  EXPECT_EQ(0U, offset);
+  offset = 0;
+  EXPECT_EQ(0U, BE.GetMaxU64(&offset, 0));
+  EXPECT_EQ(0U, offset);
+
+  offset = 0;
+  EXPECT_EQ(0x01U, LE.GetMaxU64(&offset, 1));
+  EXPECT_EQ(1U, offset);
+  offset = 0;
+  EXPECT_EQ(0x01U, BE.GetMaxU64(&offset, 1));
+  EXPECT_EQ(1U, offset);
+
+  // Check with a non-zero offset.
+  offset = 1;
+  EXPECT_EQ(0x0302U, LE.GetMaxU64(&offset, 2));
+  EXPECT_EQ(3U, offset);
+  offset = 1;
+  EXPECT_EQ(0x0203U, BE.GetMaxU64(&offset, 2));
+  EXPECT_EQ(3U, offset);
+
+  // Check with the byte size not being a multiple of 2.
+  offset = 0;
+  EXPECT_EQ(0x07060504030201U, LE.GetMaxU64(&offset, 7));
+  EXPECT_EQ(7U, offset);
+  offset = 0;
+  EXPECT_EQ(0x01020304050607U, BE.GetMaxU64(&offset, 7));
+  EXPECT_EQ(7U, offset);
+
+  // Check with the maximum allowed byte size.
+  offset = 0;
+  EXPECT_EQ(0x0807060504030201U, LE.GetMaxU64(&offset, 8));
+  EXPECT_EQ(8U, offset);
+  offset = 0;
+  EXPECT_EQ(0x0102030405060708U, BE.GetMaxU64(&offset, 8));
+  EXPECT_EQ(8U, offset);
+}
+
+TEST(DataExtractorTest, GetMaxS64) {
+  uint8_t buffer[] = {0x01, 0x02, 0x83, 0x04, 0x05, 0x06, 0x07, 0x08};
+  DataExtractor LE(buffer, sizeof(buffer), lldb::eByteOrderLittle,
+   sizeof(void *));
+  DataExtractor BE(buffer, sizeof(buffer), lldb::eByteOrderBig, sizeof(void *));
+
+  lldb::offset_t offset;
+
+  // Check a trivial case with the byte size equal to 0.
+  offset = 0;
+  EXPECT_EQ(0, LE.GetMaxS64(&offset, 0));
+  EXPECT_EQ(0U, offset);
+  offset = 0;
+  EXPECT_EQ(0, BE.GetMaxS64(&offset, 0));
+  EXPECT_EQ(0U, offset);
+
+  // Check that sign extension works correctly.
+  offset = 0;
+  int64_t value = LE.GetMaxS64(&offset, 3);
+  EXPECT_EQ(0xff830201U, *reinterpret_cast(&value));
+  EXPECT_EQ(3U, offset);
+  offset = 2;
+  value = BE.GetMaxS64(&offset, 3);
+  EXPECT_EQ(0xff830405U, *reinterpret_cast(&value));
+  EXPECT_EQ(5U, offset);
+
+  // Check with the maximum allowed byte size.
+  offset = 0;
+  EXPECT_EQ(0x0807060504830201, LE.GetMaxS64(&offset, 8));
+  EXPECT_EQ(8U, offset);
+  offset = 0;
+  EXPECT_EQ(0x0102830405060708, BE.GetMaxS64(&offset, 8));
+  EXPECT_EQ(8U, offset);
+}
Index: source/Utility/DataExtractor.cpp
===
--- source/Utility/DataExtractor.cpp
+++ source/Utility/DataExtractor.cpp
@@ -563,21 +563,8 @@
 //--
 uint32_t DataExtractor::GetMaxU32(offset_t *offset_ptr,
   size_t byte_size) const {
-  switch (byte_size) {
-  case 1:
-return GetU8(offset_ptr);
-break;
-  case 2:
-return GetU16(offset_ptr);
-break;
-  case 4:
-return GetU32(offset_ptr);
-break;
-  default:
-assert(false && "GetMaxU32 unhandled case!");
-break;
-  }
-  return 0;
+  assert(byte_size <= 4 && "GetMaxU32 unhandled case!");
+  return GetMaxU64(offset_ptr, byte_size);
 }
 
 //

[Lldb-commits] [PATCH] D38323: Enable breakpoints and read/write GPRs for ppc64le

2017-09-29 Thread Alexandre Yukio Yamashita via Phabricator via lldb-commits
alexandreyy marked 6 inline comments as done.
alexandreyy added a comment.

In https://reviews.llvm.org/D38323#883429, @clayborg wrote:

> Looks fine. One main questions for new linux archs in particular: is linux 
> using the lldb-server to debug these days even when debugging locally? If so, 
> then this patch only needs to implement both a native register content and 
> not the lldb_private::RegisterContext subclass.


When I debug locally, the lldb launches the lldb-server. 
However, the remote debug is not working yet. The server crashes when I try to 
launch a process.

It shows that error:
lldb-server: 
/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerPlatform.cpp:134:
 lldb_private::Status 
lldb_private::process_gdb_remote::GDBRemoteCommunicationServerPlatform::LaunchGDBServer(const
 lldb_private::Args&, std::__cxx11::string, lldb::pid_t&, uint16_t&, 
std::__cxx11::string&): Assertion `ok' failed.

I will investigate that later.




Comment at: 
source/Plugins/Process/Linux/NativeRegisterContextLinux_ppc64le.h:57-64
+  struct RegInfo {
+uint32_t num_registers;
+uint32_t num_gpr_registers;
+
+uint32_t last_gpr;
+
+uint32_t gpr_flags;

clayborg wrote:
> Any reason for this struct? Just make each member a member variable of the 
> containing class? Is this passed an API somewhere and thus needed?
I implemented this class based on the ARM code, copying that struct.
We don't really need it. I will remove that.



Comment at: 
source/Plugins/Process/Linux/NativeRegisterContextLinux_ppc64le.h:66-68
+  struct Reg {
+uint8_t bytes[8];
+  };

clayborg wrote:
> Any reason to not use "uint64_t" instead of "struct Reg"?
Changed to uint64_t.



Comment at: source/Plugins/Process/Linux/NativeRegisterContextLinux_ppc64le.h:71
+  RegInfo m_reg_info;
+  Reg m_gpr_ppc64le[48]; // 64-bit general purpose registers.
+

clayborg wrote:
> Could we share the structure that backs all registers from the 
> RegisterInfos_ppc64le.h file here? Or are there multiple flavors of registers 
> for different OSs and this is just big enough for both?
Yes, we can. Better that way.
I will change that. 



Comment at: source/Plugins/Process/Utility/RegisterContextPOSIX_ppc64le.h:55-61
+  struct RegInfo {
+uint32_t num_registers;
+uint32_t num_gpr_registers;
+
+uint32_t last_gpr;
+
+uint32_t gpr_flags;

clayborg wrote:
> Any reason for this struct? Just members of the class?
File removed from patch.



Comment at: source/Plugins/Process/Utility/RegisterContextPOSIX_ppc64le.h:64-66
+  struct Reg {
+uint8_t bytes[8];
+  };

clayborg wrote:
> clayborg wrote:
> > uint64_t instead?
> Could we share the structure that backs all registers from the 
> RegisterInfos_ppc64le.h file here? Or are there multiple flavors of registers 
> for different OSs and this is just big enough for both?
File removed from patch.



Comment at: source/Plugins/Process/Utility/RegisterContextPOSIX_ppc64le.h:64-69
+  struct Reg {
+uint8_t bytes[8];
+  };
+
+  // 64-bit general purpose registers.
+  Reg m_gpr_ppc64le[48]; // 64-bit general purpose registers.

alexandreyy wrote:
> clayborg wrote:
> > clayborg wrote:
> > > uint64_t instead?
> > Could we share the structure that backs all registers from the 
> > RegisterInfos_ppc64le.h file here? Or are there multiple flavors of 
> > registers for different OSs and this is just big enough for both?
> File removed from patch.
File removed from patch.


https://reviews.llvm.org/D38323



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


[Lldb-commits] [PATCH] D38323: Enable breakpoints and read/write GPRs for ppc64le

2017-09-29 Thread Alexandre Yukio Yamashita via Phabricator via lldb-commits
alexandreyy updated this revision to Diff 117197.
alexandreyy marked 6 inline comments as done.
alexandreyy added a comment.

Remove duplicated structs and change register set types


https://reviews.llvm.org/D38323

Files:
  source/Plugins/Process/Linux/CMakeLists.txt
  source/Plugins/Process/Linux/NativeProcessLinux.cpp
  source/Plugins/Process/Linux/NativeRegisterContextLinux_ppc64le.cpp
  source/Plugins/Process/Linux/NativeRegisterContextLinux_ppc64le.h
  source/Plugins/Process/Utility/CMakeLists.txt
  source/Plugins/Process/Utility/RegisterInfoPOSIX_ppc64le.cpp
  source/Plugins/Process/Utility/RegisterInfoPOSIX_ppc64le.h
  source/Plugins/Process/Utility/RegisterInfos_ppc64le.h
  source/Plugins/Process/Utility/lldb-ppc64le-register-enums.h
  source/Target/Platform.cpp
  source/Target/Thread.cpp
  source/Utility/PPC64LE_DWARF_Registers.h
  source/Utility/PPC64LE_ehframe_Registers.h

Index: source/Utility/PPC64LE_ehframe_Registers.h
===
--- /dev/null
+++ source/Utility/PPC64LE_ehframe_Registers.h
@@ -0,0 +1,63 @@
+//===-- PPC64LE_ehframe_Registers.h -*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef utility_PPC64LE_ehframe_Registers_h_
+#define utility_PPC64LE_ehframe_Registers_h_
+
+// The register numbers used in the eh_frame unwind information.
+// Should be the same as DWARF register numbers.
+
+namespace ppc64le_ehframe {
+
+enum {
+  r0 = 0,
+  r1,
+  r2,
+  r3,
+  r4,
+  r5,
+  r6,
+  r7,
+  r8,
+  r9,
+  r10,
+  r11,
+  r12,
+  r13,
+  r14,
+  r15,
+  r16,
+  r17,
+  r18,
+  r19,
+  r20,
+  r21,
+  r22,
+  r23,
+  r24,
+  r25,
+  r26,
+  r27,
+  r28,
+  r29,
+  r30,
+  r31,
+  lr = 65,
+  ctr,
+  cr = 68,
+  xer = 76,
+  pc,
+  softe,
+  trap,
+  origr3,
+  msr,
+};
+}
+
+#endif // utility_PPC64LE_ehframe_Registers_h_
Index: source/Utility/PPC64LE_DWARF_Registers.h
===
--- /dev/null
+++ source/Utility/PPC64LE_DWARF_Registers.h
@@ -0,0 +1,63 @@
+//===-- PPC64LE_DWARF_Registers.h ---*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef utility_PPC64LE_DWARF_Registers_h_
+#define utility_PPC64LE_DWARF_Registers_h_
+
+#include "lldb/lldb-private.h"
+
+namespace ppc64le_dwarf {
+
+enum {
+  dwarf_r0_ppc64le = 0,
+  dwarf_r1_ppc64le,
+  dwarf_r2_ppc64le,
+  dwarf_r3_ppc64le,
+  dwarf_r4_ppc64le,
+  dwarf_r5_ppc64le,
+  dwarf_r6_ppc64le,
+  dwarf_r7_ppc64le,
+  dwarf_r8_ppc64le,
+  dwarf_r9_ppc64le,
+  dwarf_r10_ppc64le,
+  dwarf_r11_ppc64le,
+  dwarf_r12_ppc64le,
+  dwarf_r13_ppc64le,
+  dwarf_r14_ppc64le,
+  dwarf_r15_ppc64le,
+  dwarf_r16_ppc64le,
+  dwarf_r17_ppc64le,
+  dwarf_r18_ppc64le,
+  dwarf_r19_ppc64le,
+  dwarf_r20_ppc64le,
+  dwarf_r21_ppc64le,
+  dwarf_r22_ppc64le,
+  dwarf_r23_ppc64le,
+  dwarf_r24_ppc64le,
+  dwarf_r25_ppc64le,
+  dwarf_r26_ppc64le,
+  dwarf_r27_ppc64le,
+  dwarf_r28_ppc64le,
+  dwarf_r29_ppc64le,
+  dwarf_r30_ppc64le,
+  dwarf_r31_ppc64le,
+  dwarf_lr_ppc64le = 65,
+  dwarf_ctr_ppc64le,
+  dwarf_cr_ppc64le = 68,
+  dwarf_xer_ppc64le = 76,
+  dwarf_pc_ppc64le,
+  dwarf_softe_ppc64le,
+  dwarf_trap_ppc64le,
+  dwarf_origr3_ppc64le,
+  dwarf_msr_ppc64le,
+};
+
+} // namespace ppc64le_dwarf
+
+#endif // utility_PPC64LE_DWARF_Registers_h_
Index: source/Target/Thread.cpp
===
--- source/Target/Thread.cpp
+++ source/Target/Thread.cpp
@@ -2075,6 +2075,7 @@
 case llvm::Triple::mips64el:
 case llvm::Triple::ppc:
 case llvm::Triple::ppc64:
+case llvm::Triple::ppc64le:
 case llvm::Triple::systemz:
 case llvm::Triple::hexagon:
   m_unwinder_ap.reset(new UnwindLLDB(*this));
Index: source/Target/Platform.cpp
===
--- source/Target/Platform.cpp
+++ source/Target/Platform.cpp
@@ -1878,6 +1878,12 @@
 trap_opcode_size = sizeof(g_ppc_opcode);
   } break;
 
+  case llvm::Triple::ppc64le: {
+static const uint8_t g_ppc64le_opcode[] = {0x08, 0x00, 0xe0, 0x7f}; // trap
+trap_opcode = g_ppc64le_opcode;
+trap_opcode_size = sizeof(g_ppc64le_opcode);
+  } break;
+
   case llvm::Triple::x86:
   case llvm::Triple::x86_64: {
 static const uint8_t g_i386_opcode[] = {0xCC};
Index: source/Plugins/Process/Utility/lldb-ppc64le-register-enums.h
===
--- /dev/null
+++ source/Plugins/Process/Utility/lldb-ppc64le-register

[Lldb-commits] [PATCH] D38394: Fix dumping of characters with non-standard sizes

2017-09-29 Thread Jim Ingham via Phabricator via lldb-commits
jingham added a comment.

This looks fine to me.  I'd give Greg a little time to weigh in, this is much 
more his code than mine.  But I don't see any problem with this, and thanks for 
the tests!




Comment at: source/Core/DumpDataExtractor.cpp:275-281
+  // Reject invalid item_byte_size.
+  if (item_byte_size > 8) {
+s->Printf("error: unsupported byte size (%" PRIu64 ") for char format",
+  (uint64_t)item_byte_size);
+return offset;
+  }
+

Should this consume the weird input we couldn't print?  I actually don't have a 
good feel for which would be better.



Comment at: source/Utility/DataExtractor.cpp:566
   size_t byte_size) const {
-  switch (byte_size) {
-  case 1:
-return GetU8(offset_ptr);
-break;
-  case 2:
-return GetU16(offset_ptr);
-break;
-  case 4:
-return GetU32(offset_ptr);
-break;
-  default:
-assert(false && "GetMaxU32 unhandled case!");
-break;
-  }
-  return 0;
+  assert(byte_size <= 4 && "GetMaxU32 unhandled case!");
+  return GetMaxU64(offset_ptr, byte_size);

This is trivial, and you didn't change what was there, but this message makes 
it sound like this is just something we haven't gotten to yet.  It's really 
"You passed in an illegal byte size"...  Might be clearer if the message said 
that.


https://reviews.llvm.org/D38394



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


[Lldb-commits] Buildbot numbers for the week of 09/03/2017 - 09/09/2017

2017-09-29 Thread Galina Kistanova via lldb-commits
Hello everyone,

Below are some buildbot numbers for the week of 09/03/2017 - 09/09/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-lnt   | 96:22:57
 llvm-mips-linux | 87:07:26
 clang-ppc64be-linux-multistage  | 86:13:04
 clang-ppc64be-linux-lnt | 85:19:29
 clang-ppc64be-linux | 85:17:30
 clang-s390x-linux   | 85:09:14
 reverse-iteration   | 72:01:21
 perf-x86_64-penryn-O3-polly-fast| 59:07:55
 perf-x86_64-penryn-O3-polly | 58:04:43
 sanitizer-x86_64-linux-fast | 40:08:18
 sanitizer-x86_64-linux-bootstrap| 39:36:59
 ubuntu-gcc7.1-werror| 26:34:15
 libcxx-libcxxabi-singlethreaded-x86_64-linux-debian | 24:51:06
 libcxx-libcxxabi-x86_64-linux-debian-noexceptions   | 24:32:30
 libcxx-libcxxabi-libunwind-x86_64-linux-debian  | 24:14:11
 libcxx-libcxxabi-x86_64-linux-debian| 23:58:11
 llvm-clang-x86_64-expensive-checks-win  | 17:18:19
 clang-x86-windows-msvc2015  | 16:40:52
 clang-x64-ninja-win7| 16:37:36
 clang-with-thin-lto-windows | 16:24:57
 clang-cmake-aarch64-full| 12:37:44
 clang-cmake-aarch64-quick   | 08:38:36
 clang-lld-x86_64-2stage | 06:01:58
 polly-amd64-linux   | 05:29:44
 clang-cmake-armv7-a15-selfhost  | 05:00:13
 clang-x86_64-debian-fast| 04:19:21
 clang-ppc64le-linux-multistage  | 03:37:01
 clang-cmake-aarch64-global-isel | 03:33:00
 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast| 03:10:27
 clang-cmake-aarch64-lld | 03:07:39
 sanitizer-x86_64-linux-autoconf | 03:01:08
 libcxx-libcxxabi-libunwind-arm-linux| 02:59:25
 sanitizer-ppc64le-linux | 02:45:58
 clang-ppc64le-linux-lnt | 02:44:36
 clang-x86_64-linux-abi-test | 02:39:32
 lldb-x86_64-darwin-13.4 | 02:13:20
 sanitizer-ppc64be-linux | 02:12:57
 clang-with-lto-ubuntu   | 02:06:39
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03  | 01:56:50
 clang-with-thin-lto-ubuntu  | 01:51:03
 clang-cmake-x86_64-avx2-linux   | 01:49:23
 clang-x86_64-linux-selfhost-modules | 01:46:33
 clang-x86_64-linux-selfhost-modules-2   | 01:43:53
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx1z-32bit| 01:39:55
 clang-cuda-build| 01:37:11
 clang-ppc64le-linux | 01:35:39
 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast  | 01:35:21
 clang-atom-d525-fedora-rel  | 01:35:12
 sanitizer-x86_64-linux  | 01:33:19
 clang-native-arm-lnt| 01:33:01
 clang-cmake-x86_64-sde-avx512-linux | 01:31:53
 clang-cmake-thumbv7-a15 | 01:20:51
 sanitizer-x86_64-linux-android  | 01:16:15
 lldb-amd64-ninja-netbsd8| 01:13:56
 clang-cmake-x86_64-avx2-linux-perf  | 01:11:23
 clang-hexagon-elf   | 01:11:23
 clang-cmake-armv7-a15-full  | 01:09:21
 lldb-x86_64-ubuntu-14.04-buildserver| 01:08:55
 lld-x86_64-darwin13 | 01:07:27
 lldb-x86_64-ubuntu-14.04-cmake  | 01:05:45
 sanitizer-x86_64-linux-fuzzer   | 00:55:59
 lldb-x86_64-ubuntu-14.04-android| 00:54:55
 clang-cmake-armv7-a15   | 00:32:13
 libcxx-libcxxabi-x86_64-linux-ubuntu-asan   | 00:31:16
 lldb-amd64-ninja-freebsd11  | 00:23:03
 lld-x86_64-freebsd  | 00:13:46
 sanitizer-windows 

[Lldb-commits] Buildbot numbers for the week of 09/10/2017 - 09/16/2017

2017-09-29 Thread Galina Kistanova via lldb-commits
Hello everyone,

Below are some buildbot numbers for the week of 09/10/2017 - 09/16/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
---+-
 lld-x86_64-freebsd| 77:38:11
 clang-cuda-build  | 72:56:52
 lldb-windows7-android | 66:57:22
 clang-with-lto-ubuntu | 65:59:18
 clang-ppc64le-linux-lnt   | 64:29:58
 llvm-clang-lld-x86_64-debian-fast | 63:49:23
 clang-x64-ninja-win7  | 52:11:20
 clang-ppc64be-linux-lnt   | 49:14:32
 llvm-mips-linux   | 48:10:18
 clang-ppc64be-linux   | 47:06:24
 clang-ppc64be-linux-multistage| 45:46:21
 clang-with-thin-lto-ubuntu| 42:11:36
 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast| 31:35:29
 sanitizer-x86_64-linux-fast   | 25:01:14
 reverse-iteration | 24:10:32
 lldb-amd64-ninja-netbsd8  | 22:55:55
 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast  | 21:46:04
 libcxx-libcxxabi-x86_64-linux-debian  | 20:27:42
 libcxx-libcxxabi-libunwind-x86_64-linux-debian| 20:18:42
 sanitizer-x86_64-linux-bootstrap  | 16:25:47
 perf-x86_64-penryn-O3-polly-detect-only   | 14:34:58
 perf-x86_64-penryn-O3 | 14:14:57
 clang-x86_64-linux-selfhost-modules-2 | 13:36:45
 perf-x86_64-penryn-O3-polly   | 13:19:43
 clang-cmake-x86_64-sde-avx512-linux   | 13:17:40
 clang-x86-windows-msvc2015| 13:13:48
 llvm-clang-x86_64-expensive-checks-win| 13:04:58
 clang-cmake-x86_64-avx2-linux | 12:58:45
 clang-cmake-x86_64-avx2-linux-perf| 12:57:46
 clang-cmake-armv7-a15-selfhost-neon   | 11:51:13
 libcxx-libcxxabi-x86_64-linux-debian-noexceptions | 11:26:49
 sanitizer-ppc64be-linux   | 11:10:28
 sanitizer-x86_64-linux| 10:15:05
 sanitizer-x86_64-linux-android| 09:44:37
 clang-cmake-armv7-a15-selfhost| 09:31:35
 clang-lld-x86_64-2stage   | 08:20:55
 perf-x86_64-penryn-O3-polly-fast  | 07:39:33
 sanitizer-x86_64-linux-autoconf   | 06:32:19
 libcxx-libcxxabi-libunwind-arm-linux-noexceptions | 05:55:01
 clang-x86_64-linux-selfhost-modules   | 05:20:30
 ubuntu-gcc7.1-werror  | 05:17:58
 libcxx-libcxxabi-libunwind-aarch64-linux  | 05:09:02
 clang-x86_64-linux-abi-test   | 05:04:51
 clang-cmake-aarch64-lld   | 04:59:45
 clang-cmake-aarch64-global-isel   | 04:41:28
 clang-with-thin-lto-windows   | 04:41:03
 clang-cmake-aarch64-full  | 04:00:30
 clang-x86_64-debian-fast  | 03:59:45
 sanitizer-windows | 03:40:31
 clang-ppc64le-linux-multistage| 03:25:12
 lldb-x86_64-ubuntu-14.04-cmake| 03:18:36
 lldb-x86_64-darwin-13.4   | 03:13:30
 clang-cmake-aarch64-quick | 03:03:39
 clang-native-arm-lnt  | 02:52:10
 lldb-x86_64-ubuntu-14.04-android  | 02:18:02
 clang-ppc64le-linux   | 02:06:17
 polly-amd64-linux | 02:00:44
 clang-s390x-linux | 01:54:43
 clang-atom-d525-fedora-rel| 01:52:21
 clang-s390x-linux-lnt | 01:47:11
 clang-cmake-armv7-a15 | 01:36:24
 clang-cmake-thumbv7-a15   | 01:36:19
 lldb-x86-windows-msvc2015 | 01:31:21
 clang-hexagon-elf | 01:09:53
 lldb-x86_64-ubuntu-14.04-buildserver  | 01:08:20
 sanitizer-x86_64-linux-fuzzer | 01:06:33
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03| 01:01:59
 llvm-hexagon-elf  | 01:00:17
 lld-x86_64-darwin13   

[Lldb-commits] Buildbot numbers for the week of 09/17/2017 - 09/23/2017

2017-09-29 Thread Galina Kistanova via lldb-commits
Hello everyone,

Below are some buildbot numbers for the last week of 09/17/2017 -
09/23/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  | 65:09:50
 clang-cmake-aarch64-global-isel   | 43:46:11
 clang-x86-windows-msvc2015| 42:27:37
 clang-cmake-armv7-a15-selfhost| 41:20:55
 clang-cuda-build  | 40:55:08
 clang-cmake-armv7-a15-selfhost-neon   | 37:36:22
 clang-ppc64le-linux-multistage| 37:19:48
 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast| 36:01:53
 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast  | 35:56:46
 clang-ppc64le-linux-lnt   | 35:31:01
 clang-atom-d525-fedora-rel| 34:51:34
 clang-cmake-x86_64-sde-avx512-linux   | 34:41:42
 sanitizer-windows | 34:39:52
 clang-x86_64-linux-selfhost-modules-2 | 34:39:01
 clang-ppc64le-linux   | 33:28:48
 clang-ppc64be-linux   | 32:04:32
 clang-s390x-linux | 27:40:10
 lldb-x86_64-darwin-13.4   | 27:33:10
 lldb-windows7-android | 27:15:05
 clang-ppc64be-linux-lnt   | 27:02:19
 lldb-x86_64-ubuntu-14.04-android  | 26:37:13
 llvm-mips-linux   | 26:34:19
 clang-s390x-linux-lnt | 26:23:34
 clang-with-lto-ubuntu | 25:31:49
 clang-ppc64be-linux-multistage| 25:17:55
 libcxx-libcxxabi-x86_64-linux-ubuntu-asan | 25:03:31
 libcxx-libcxxabi-libunwind-aarch64-linux  | 18:19:23
 ubuntu-gcc7.1-werror  | 17:42:44
 lldb-x86_64-ubuntu-14.04-cmake| 15:50:29
 sanitizer-ppc64be-linux   | 14:46:46
 sanitizer-x86_64-linux| 13:58:07
 clang-with-thin-lto-ubuntu| 13:39:30
 clang-x86_64-linux-selfhost-modules   | 13:10:13
 clang-lld-x86_64-2stage   | 12:01:51
 clang-cmake-aarch64-lld   | 11:12:46
 sanitizer-x86_64-linux-bootstrap  | 11:11:32
 sanitizer-x86_64-linux-fast   | 09:51:43
 llvm-clang-lld-x86_64-debian-fast | 07:33:04
 clang-cmake-armv7-a15 | 07:17:37
 clang-cmake-thumbv7-a15   | 07:17:34
 polly-amd64-linux | 07:11:53
 clang-cmake-x86_64-avx2-linux | 06:50:06
 perf-x86_64-penryn-O3-polly-detect-only   | 06:48:48
 llvm-clang-x86_64-expensive-checks-win| 06:47:03
 llvm-hexagon-elf  | 06:46:59
 clang-x86_64-debian-fast  | 06:46:59
 clang-x64-ninja-win7  | 06:45:57
 clang-hexagon-elf | 06:45:07
 clang-native-arm-lnt  | 06:42:10
 clang-cmake-aarch64-full  | 06:42:09
 clang-with-thin-lto-windows   | 06:29:55
 polly-arm-linux   | 06:29:54
 clang-cmake-x86_64-avx2-linux-perf| 06:04:57
 clang-cmake-aarch64-quick | 05:28:48
 libcxx-libcxxabi-libunwind-x86_64-linux-debian| 05:03:54
 sanitizer-x86_64-linux-autoconf   | 04:39:58
 lld-x86_64-darwin13   | 04:05:16
 lldb-x86_64-ubuntu-14.04-buildserver  | 02:15:56
 libcxx-libcxxabi-x86_64-linux-ubuntu-ubsan| 01:35:39
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11| 01:27:11
 clang-x86_64-linux-abi-test   | 01:25:16
 lldb-x86-windows-msvc2015 | 01:23:50
 libcxx-libcxxabi-libunwind-arm-linux-noexceptions | 01:23:12
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14| 01:22:22
 lldb-amd6