[Lldb-commits] [PATCH] D32930: New framework for lldb client-server communication tests.
labath added inline comments.
Comment at: unittests/tools/lldb-server/tests/MessageObjects.h:10
+
+#include
+#include
jmajors wrote:
> labath wrote:
> > This still looks wrong. Did you run clang-format on the full patch (`git
> > clang-format origin/master` should do the trick. you may need to set the
> > clangFormat.binary git setting to point to a clang-format executable) ?
> I ran clang-format -i *h *cpp. It reordered the includes.
> I just ran it as a git subcommand, and it didn't change these lines.
> I even tried scrambling the includes around, and that's the order it seems
> to want them in.
Right, I think you're using the weird system clang-format present on google
workstations. We can't use this one because it seems to hardcode google style,
or something like that. Please try again using a clang-format built from
upstream directly. When I did that on your patch, it put the includes in the
correct order (and also fixed some other small style inconsistencies)
Comment at: unittests/tools/lldb-server/tests/MessageObjects.h:52
+
+ unsigned long ReadRegister(unsigned long register_id) const;
+
tberghammer wrote:
> "unsigned long" is only 32 bit on some systems but a register can be
> arbitrary large so the return value should be something more generic. This is
> true for every location you are working with registers.
changing to uint64_t does not really solve the issue Tamas was pointing out, it
possibly even makes it worse. The reason I did not bring it up until now is
that `long` happens match the size of general purpose registers, which are the
ones that we care about for the moment, which was kinda nice.
However, intel sse registers can be up to 512 bits wide, so we will need to
have something more generic sooner or later. lldb has a `RegisterValue` class
for this purpose, so we should probably use that. If it shows that it makes
the code too clunky, we can add some accessor functions which assert that the
size of register is e.g. sizeof(void*) and return a simple integer. They can
then be used it cases where you know that the register must contain a
pointer-sized value.
Comment at: unittests/tools/lldb-server/tests/MessageObjects.h:63
+ public:
+ static llvm::Expected> Create(
+ llvm::StringRef response, llvm::support::endianness endian);
jmajors wrote:
> tberghammer wrote:
> > Why do we need the unique_ptr here? Can it return
> > llvm::Expected instead? Same question for the other Create
> > functions.
> Since I don't build the JThreadsInfo, ProcessInfo, and StopReply members of
> TestClient in the constructor, I'd need a default constructor, which I hid to
> force use of Create(). Also, it allows me to have an uninitialized value for
> these members, so I can verify some things happen in the correct order.
Avoiding a constructed-but-invalid object is certainly a worthwhile goal.
Technically you can have that *and* avoid the unique_ptr here by having the
test client store llvm::Optional as a member, which you then
initialize after you get a proper jthreadsinfo response.
It would make the interface of this function nicer to use (you can write
`result->GetThreadInfoMap()` instead of `result.get()->GetThreadInfoMap()`),
but that is not too high on my list of priorities right now.
(actually, I am wondering now whether you really need the wrapper class, or the
Create function could return the ThreadInfoMap object directly)
Comment at: unittests/tools/lldb-server/tests/MessageObjects.h:91
+// Common functions for parsing packet data.
+llvm::Error make_parsing_error(const char *format, uint64_t number);
+llvm::Error make_parsing_error(llvm::StringRef parse_target);
We can have both of these (and any other combination of arguments we want to by
making this a template)
```
template
llvm::Error make_parsing_error(llvm::StringRef format, Args &&... args) {
std::string error = "Unable to parse " + formatv(format,
std::forward(args)...).str();
return make_error(error, inconvertibleErrorCode());
}
```
should do the trick (after you fix the compile errors).
The interface of this function will then be the same as formatv, except it will
return an error.
Comment at: unittests/tools/lldb-server/tests/MessageObjects.h:41
+private:
+ std::string source;
+};
tberghammer wrote:
> The LLDB coding convention is to prefix member variables with "m_". Do we
> want to follow that one here or should we follow the LLVM one what is
> CapitalCase (you are following neither of them at the moment)?
Agreed.
Comment at: unittests/tools/lldb-server/tests/TestClient.cpp:62
+.str();
+GTEST_LOG_(ERROR) << error;
+return false;
jmajors wrote:
> labath wrote:
> > This won't actually fail the test (i'm not sure whether you intended that
> > or not). I
[Lldb-commits] [PATCH] D32930: New framework for lldb client-server communication tests.
tberghammer added inline comments.
Comment at: unittests/tools/lldb-server/inferior/thread_inferior.cpp:22
+
+ bool delay = true;
+ std::vector threads;
You have to make this variable atomic (or add a mutex) to make it work. In the
current implementation there is no guarantee that the new threads will ever see
the updated value as (in theory) the compiler can optimize away the repeated
read.
Comment at: unittests/tools/lldb-server/tests/MessageObjects.cpp:54
+
+ProcessInfo::ProcessInfo() {}
+
(nit): You can use "ProcessInfo() = default;" in the header file (here and in
every other empty constructor/destructor)
Comment at: unittests/tools/lldb-server/tests/MessageObjects.h:33-42
+ lldb::pid_t pid;
+ lldb::pid_t parent_pid;
+ uint32_t real_uid;
+ uint32_t real_gid;
+ uint32_t effective_uid;
+ uint32_t effective_gid;
+ std::string triple;
A large part of these variables are never read by anybody. Do we want to keep
them around just in case or should we remove them?
https://reviews.llvm.org/D32930
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32930: New framework for lldb client-server communication tests.
krytarowski added inline comments. Comment at: unittests/tools/lldb-server/tests/TestClient.cpp:115 + + if (thread_id == 0) thread_id = process_info->GetPid(); + labath wrote: > jmajors wrote: > > labath wrote: > > > This is a linux-ism. Other targets don't have the "pid == main thread id" > > > concept. What is the semantics you intended for the thread_id = 0 case? > > > If you wanted to resume the whole process (all threads) you can send > > > `vCont;c` or just `c`. We also have the LLDB_INVALID_THREAD_ID symbolic > > > constant to signify invalid thread. > > I was using 0 so the caller didn't have to know what the main thread id was. > Right, so this won't work because on netbsd (I believe) the main thread will > have tid = 1. > > We could start special-casing the individual platforms here to get the right > behaviour, but I am not sure the > i-want-to-resume-only-the-main-thread-but-i-can't-be-bothered-to-look-it-up > case is common enough for that -- If you don't have a thread ID handy, most > of the time you will want to resume the whole process instead. So I think we > should have two functions, one that resumes the whole process (which takes no > arguments), and one that resumes only a single thread (and takes a mandatory > argument). > > (also the argument type should be lldb::tid_t) This is correct, process has it's PID, and it has one or more LWPs (threads). The main thread is 1, and it's counting 2,3,4 for second, third, fourth etc. Thread 0 is internally (and at least in ptrace(2)) reserved for "all process" events. If I know correctly, the same model is in Solaris. https://reviews.llvm.org/D32930 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32522: Test case for the issue raised in D32271
emaste added a comment.
Two small nits noted inline, but now the test does not pass without
https://reviews.llvm.org/D32271 and does with it. Note that in the "without"
case it returned error rather than failing, perhaps related to the path issue I
noted?
Other than that issue I think this is good to go. So hopefully that can be
addressed, then one of the Linux folks can confirm it's good to go. IMO it's
fine for this to go in first demonstrating the bug on FreeBSD followed by a
commit of https://reviews.llvm.org/D32271.
Comment at:
packages/Python/lldbsuite/test/functionalities/process_attach/TestProcessAttach.py:42
+def test_attach_to_process_frm_different_dir_by_id(self):
+"""Test attach by process id"""
s/frm/from/ perhaps?
Comment at:
packages/Python/lldbsuite/test/functionalities/process_attach/TestProcessAttach.py:47
+exe = os.path.join('.','newdir','proc_attach')
+self.addTearDownHook(lambda: shutil.rmtree(os.path.join(os.getcwd(
+
shouldn't this be ... `rmtree(os.path.join(os.getcwd(), 'newdir'))` instead?
Repository:
rL LLVM
https://reviews.llvm.org/D32522
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32271: Patch to Attach pid successfully from different dir
dim added a comment. As I found out in https://reviews.llvm.org/rL303015, the `KERN_PROC_PATHNAME` has one drawback: if an executable file has multiple hard links, you will get just one of its filenames as the result. Since that filename is more or less randomly chosen, it does *not* have to correspond to the actual `argv[0]` the executable was invoked with. If that does not matter, this approach is fine, though. https://reviews.llvm.org/D32271 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32271: Patch to Attach pid successfully from different dir
krytarowski added a comment. If we end up with hard links I think we should change them to symbolic ones. This is a common policy in some open source distributions. https://reviews.llvm.org/D32271 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32271: Patch to Attach pid successfully from different dir
emaste added a comment. In https://reviews.llvm.org/D32271#759361, @dim wrote: > As I found out in https://reviews.llvm.org/rL303015, the `KERN_PROC_PATHNAME` > has one drawback: if an executable file has multiple hard links, you will get > just one of its filenames as the result. Since that filename is more or less > randomly chosen, it does *not* have to correspond to the actual `argv[0]` the > executable was invoked with. If that does not matter, this approach is fine, > though. Thanks @dim, it's because of https://reviews.llvm.org/rL303015 that I added you to CC. Thinking about this further, I think that in this (LLDB) case it's acceptable (even if it might prove slightly surprising). If we attach via `-p ` this code is used to find the corresponding binary, and even if we open the file by the "wrong" name we still have the correct content. https://reviews.llvm.org/D32271 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r303465 - Don't override the SDKs and force the use of /System/Library/Frameworks to
Author: jmolenda Date: Fri May 19 18:00:42 2017 New Revision: 303465 URL: http://llvm.org/viewvc/llvm-project?rev=303465&view=rev Log: Don't override the SDKs and force the use of /System/Library/Frameworks to find the python headers when buiding crashinfo.c Modified: lldb/trunk/packages/Python/lldbsuite/test/configuration.py Modified: lldb/trunk/packages/Python/lldbsuite/test/configuration.py URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/configuration.py?rev=303465&r1=303464&r2=303465&view=diff == --- lldb/trunk/packages/Python/lldbsuite/test/configuration.py (original) +++ lldb/trunk/packages/Python/lldbsuite/test/configuration.py Fri May 19 18:00:42 2017 @@ -44,7 +44,7 @@ def setupCrashInfoHook(): if not os.path.isfile(dylib_dst) or os.path.getmtime( dylib_dst) < os.path.getmtime(dylib_src): # we need to compile -cmd = "SDKROOT= xcrun clang %s -o %s -framework Python -Xlinker -dylib -iframework /System/Library/Frameworks/ -Xlinker -F /System/Library/Frameworks/" % ( +cmd = "SDKROOT= xcrun clang %s -o %s -framework Python -Xlinker -dylib" % ( dylib_src, dylib_dst) if subprocess.call( cmd, shell=True) != 0 or not os.path.isfile(dylib_dst): ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32930: New framework for lldb client-server communication tests.
jmajors marked 12 inline comments as done. jmajors added inline comments. Comment at: unittests/tools/lldb-server/tests/MessageObjects.h:52 + + unsigned long ReadRegister(unsigned long register_id) const; + labath wrote: > tberghammer wrote: > > "unsigned long" is only 32 bit on some systems but a register can be > > arbitrary large so the return value should be something more generic. This > > is true for every location you are working with registers. > changing to uint64_t does not really solve the issue Tamas was pointing out, > it possibly even makes it worse. The reason I did not bring it up until now > is that `long` happens match the size of general purpose registers, which are > the ones that we care about for the moment, which was kinda nice. > > However, intel sse registers can be up to 512 bits wide, so we will need to > have something more generic sooner or later. lldb has a `RegisterValue` class > for this purpose, so we should probably use that. If it shows that it makes > the code too clunky, we can add some accessor functions which assert that the > size of register is e.g. sizeof(void*) and return a simple integer. They can > then be used it cases where you know that the register must contain a > pointer-sized value. Rather than trying to test and convert them all, I just left them as strings. I only access one value (the PC), so I'm converting it as I need it. Comment at: unittests/tools/lldb-server/tests/MessageObjects.h:33-42 + lldb::pid_t pid; + lldb::pid_t parent_pid; + uint32_t real_uid; + uint32_t real_gid; + uint32_t effective_uid; + uint32_t effective_gid; + std::string triple; tberghammer wrote: > A large part of these variables are never read by anybody. Do we want to keep > them around just in case or should we remove them? I figured I might as well parse the whole message at once, in case new tests need the pieces. https://reviews.llvm.org/D32930 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32930: New framework for lldb client-server communication tests.
jmajors updated this revision to Diff 99644.
jmajors marked an inline comment as done.
jmajors added a comment.
More feedback changes.
https://reviews.llvm.org/D32930
Files:
unittests/CMakeLists.txt
unittests/tools/CMakeLists.txt
unittests/tools/lldb-server/CMakeLists.txt
unittests/tools/lldb-server/inferior/thread_inferior.cpp
unittests/tools/lldb-server/tests/CMakeLists.txt
unittests/tools/lldb-server/tests/MessageObjects.cpp
unittests/tools/lldb-server/tests/MessageObjects.h
unittests/tools/lldb-server/tests/TestClient.cpp
unittests/tools/lldb-server/tests/TestClient.h
unittests/tools/lldb-server/tests/ThreadIdsInJstopinfoTest.cpp
Index: unittests/tools/lldb-server/tests/ThreadIdsInJstopinfoTest.cpp
===
--- /dev/null
+++ unittests/tools/lldb-server/tests/ThreadIdsInJstopinfoTest.cpp
@@ -0,0 +1,58 @@
+//===-- ThreadsInJstopinfoTest.cpp --*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "TestClient.h"
+#include "gtest/gtest.h"
+#include
+
+using namespace llgs_tests;
+
+class ThreadsInJstopinfoTest : public ::testing::Test {
+protected:
+ virtual void SetUp() { TestClient::Initialize(); }
+};
+
+TEST_F(ThreadsInJstopinfoTest, TestStopReplyContainsThreadPcsLlgs) {
+ std::vector inferior_args;
+ // This inferior spawns N threads, then forces a break.
+ inferior_args.push_back(THREAD_INFERIOR);
+ inferior_args.push_back("4");
+
+ auto test_info = ::testing::UnitTest::GetInstance()->current_test_info();
+
+ TestClient client(test_info->name(), test_info->test_case_name());
+ ASSERT_TRUE(client.StartDebugger());
+ ASSERT_TRUE(client.SetInferior(inferior_args));
+ ASSERT_TRUE(client.ListThreadsInStopReply());
+ ASSERT_TRUE(client.ContinueAll());
+ unsigned int pc_reg = client.GetPcRegisterId();
+ ASSERT_NE(pc_reg, UINT_MAX);
+
+ auto jthreads_info = client.GetJThreadsInfo();
+ ASSERT_TRUE(jthreads_info);
+
+ auto stop_reply = client.GetLatestStopReply();
+ auto stop_reply_pcs = stop_reply.GetThreadPcs();
+ auto thread_infos = jthreads_info->GetThreadInfos();
+ ASSERT_EQ(stop_reply_pcs.size(), thread_infos.size())
+ << "Thread count mismatch.";
+
+ for (auto stop_reply_pc : stop_reply_pcs) {
+unsigned long tid = stop_reply_pc.first;
+ASSERT_TRUE(thread_infos.find(tid) != thread_infos.end())
+<< "Thread ID: " << tid << " not in JThreadsInfo.";
+uint64_t pc_value;
+ASSERT_TRUE(thread_infos[tid].ReadRegisterAsUint64(pc_reg, pc_value))
+<< "Failure reading ThreadInfo register " << pc_reg;
+ASSERT_EQ(stop_reply_pcs[tid], pc_value)
+<< "Mismatched PC for thread: " << tid;
+ }
+
+ ASSERT_TRUE(client.StopDebugger());
+}
Index: unittests/tools/lldb-server/tests/TestClient.h
===
--- /dev/null
+++ unittests/tools/lldb-server/tests/TestClient.h
@@ -0,0 +1,61 @@
+//===-- TestClient.h *- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "MessageObjects.h"
+#include "Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h"
+#include "lldb/Core/ArchSpec.h"
+#include "lldb/Target/ProcessLaunchInfo.h"
+#include "llvm/ADT/Optional.h"
+#include
+#include
+
+namespace llgs_tests {
+// TODO: Make the test client an abstract base class, with different children
+// for different types of connections: llgs v. debugserver
+class TestClient
+: public lldb_private::process_gdb_remote::GDBRemoteCommunicationClient {
+public:
+ static void Initialize();
+ TestClient(const std::string &test_name, const std::string &test_case_name);
+ virtual ~TestClient();
+ LLVM_NODISCARD bool StartDebugger();
+ LLVM_NODISCARD bool StopDebugger();
+ LLVM_NODISCARD bool SetInferior(llvm::ArrayRef inferior_args);
+ LLVM_NODISCARD bool ListThreadsInStopReply();
+ LLVM_NODISCARD bool SetBreakpoint(unsigned long address);
+ LLVM_NODISCARD bool ContinueAll();
+ LLVM_NODISCARD bool ContinueThread(unsigned long thread_id);
+ const ProcessInfo &GetProcessInfo();
+ llvm::Optional GetJThreadsInfo();
+ const StopReply &GetLatestStopReply();
+ LLVM_NODISCARD bool SendMessage(llvm::StringRef message);
+ LLVM_NODISCARD bool SendMessage(llvm::StringRef message,
+ std::string &response_string);
+ LLVM_NODISCARD bool SendMessage(llvm::StringRef message,
+ std::string &response_string,
+
[Lldb-commits] Buildbot numbers for the week of 04/30/2017 - 05/06/2017
Hello everyone, Below are some buildbot numbers for the week of 04/30/2017 - 05/06/2017. Please see the same data in attached csv files: The longest time each builder was red during the last 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 last week: buildername | was_red +- sanitizer-x86_64-linux-fast| 38:52:51 sanitizer-x86_64-linux-bootstrap | 38:49:41 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast | 32:10:27 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast | 32:05:29 clang-ppc64be-linux-lnt| 21:39:00 clang-ppc64le-linux| 20:49:44 clang-ppc64le-linux-multistage | 20:39:25 clang-ppc64be-linux| 20:13:44 clang-ppc64be-linux-multistage | 19:55:41 sanitizer-ppc64be-linux| 19:34:10 sanitizer-ppc64le-linux| 19:19:32 clang-cmake-armv7-a15-selfhost | 17:53:59 clang-cmake-armv7-a15-selfhost-neon| 15:00:41 sanitizer-windows | 14:53:51 perf-x86_64-penryn-O3-polly-before-vectorizer | 14:21:27 clang-cmake-thumbv7-a15-full-sh| 13:26:48 lldb-windows7-android | 10:47:15 polly-amd64-linux | 09:43:55 polly-arm-linux| 08:59:31 clang-x86-windows-msvc2015 | 08:22:05 llvm-clang-x86_64-expensive-checks-win | 06:52:39 clang-lld-x86_64-2stage| 05:35:26 libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11 | 04:56:09 clang-cmake-aarch64-full | 04:24:35 clang-with-thin-lto-ubuntu | 04:05:06 clang-bpf-build| 03:51:45 clang-with-lto-ubuntu | 03:31:15 sanitizer-x86_64-linux | 03:11:14 lld-sphinx-docs| 02:57:07 clang-sphinx-docs | 02:56:38 clang-tools-sphinx-docs| 02:56:28 lld-x86_64-darwin13| 02:43:21 clang-cmake-aarch64-lld| 02:38:26 clang-s390x-linux | 02:09:45 clang-cuda-build | 02:02:40 perf-x86_64-penryn-O3 | 02:02:12 sanitizer-x86_64-linux-fuzzer | 01:52:53 clang-x86_64-linux-selfhost-modules| 01:45:44 clang-x86_64-linux-selfhost-modules-2 | 01:26:51 sanitizer-x86_64-linux-autoconf| 01:23:32 clang-x64-ninja-win7 | 01:22:15 perf-x86_64-penryn-O3-polly-before-vectorizer-unprofitable | 01:18:55 lldb-x86_64-ubuntu-14.04-buildserver | 01:15:35 clang-cmake-aarch64-42vma | 01:08:25 lld-x86_64-freebsd | 01:08:17 clang-hexagon-elf | 01:07:56 lldb-x86_64-darwin-13.4| 01:05:38 clang-x86_64-linux-abi-test| 01:04:30 clang-cmake-armv7-a15-full | 01:00:54 clang-x86_64-debian-fast | 00:56:39 lldb-amd64-ninja-netbsd8 | 00:56:28 clang-cmake-thumbv7-a15| 00:56:07 clang-cmake-armv7-a15 | 00:55:46 lldb-x86-windows-msvc2015 | 00:53:38 perf-x86_64-penryn-O3-polly-parallel-fast | 00:50:44 lldb-x86_64-ubuntu-14.04-android | 00:47:48 clang-native-arm-lnt | 00:45:04 llvm-hexagon-elf | 00:42:39 lld-x86_64-win7| 00:40:37 clang-cmake-aarch64-quick
[Lldb-commits] Buildbot numbers for the week of 05/07/2017 - 05/13/2017
Hello everyone, Below are some buildbot numbers for the last week of 05/07/2017 - 05/13/2017. Please see the same data in attached csv files: The longest time each builder was red during the last 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 last week: buildername | was_red +- clang-x86-windows-msvc2015 | 92:22:56 clang-x64-ninja-win7 | 75:31:27 clang-ppc64be-linux-multistage | 60:46:12 clang-ppc64be-linux-lnt| 60:18:00 clang-ppc64be-linux| 58:35:55 sanitizer-x86_64-linux | 33:16:50 clang-x86_64-linux-abi-test| 32:52:04 sanitizer-ppc64be-linux| 31:35:20 clang-ppc64le-linux-multistage | 30:26:04 clang-ppc64le-linux| 28:38:02 sanitizer-ppc64le-linux| 28:23:33 clang-cuda-build | 25:23:15 sanitizer-x86_64-linux-bootstrap | 24:17:40 clang-cmake-aarch64-39vma | 20:31:49 clang-cmake-aarch64-42vma | 20:10:59 sanitizer-x86_64-linux-fast| 19:07:17 sanitizer-x86_64-linux-autoconf| 18:41:42 libcxx-libcxxabi-libunwind-x86_64-linux-debian | 18:13:58 libcxx-libcxxabi-libunwind-arm-linux | 18:04:54 sanitizer-windows | 18:03:27 clang-bpf-build| 17:57:19 sanitizer-x86_64-linux-fuzzer | 17:10:34 lldb-x86_64-darwin-13.4| 15:08:46 perf-x86_64-penryn-O3-polly-before-vectorizer | 15:07:05 perf-x86_64-penryn-O3 | 13:04:57 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx1z | 11:23:49 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14 | 10:57:23 perf-x86_64-penryn-O3-polly| 10:44:52 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11 | 10:30:43 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03 | 10:09:00 polly-amd64-linux | 09:49:59 polly-arm-linux| 09:30:53 clang-tools-sphinx-docs| 09:29:52 libcxx-libcxxabi-libunwind-aarch64-linux | 09:01:33 libcxx-libcxxabi-x86_64-linux-ubuntu-gcc-tot-cxx1z | 08:47:16 clang-hexagon-elf | 08:22:42 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast | 08:19:42 libcxx-libcxxabi-libunwind-arm-linux-noexceptions | 08:14:08 libcxx-libcxxabi-libunwind-aarch64-linux-noexceptions | 08:13:24 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast | 07:56:42 perf-x86_64-penryn-O3-polly-before-vectorizer-detect-only | 07:39:36 perf-x86_64-penryn-O3-polly-fast | 07:35:42 clang-cmake-armv7-a15-full | 07:29:36 clang-cmake-armv7-a15-selfhost | 07:28:51 clang-cmake-aarch64-lld| 07:19:15 clang-with-lto-ubuntu | 07:12:30 clang-cmake-thumbv7-a15-full-sh| 06:56:50 clang-cmake-armv7-a15 | 06:55:54 clang-cmake-thumbv7-a15| 06:50:31 perf-x86_64-penryn-O3-polly-parallel-fast | 06:46:32 perf-x86_64-penryn-O3-polly-before-vectorizer-unprofitable | 06:17:24 clang-lld-x86_64-2stage| 05:57:13 perf-x86_64-penryn-O3-polly-unprofitable | 05:47:12 clang-cmake-armv7-a15-selfhost-neon| 05:28:37 clang-with-thin-lto-ubuntu | 05:28:04 clang-cmake-aarch64-full | 04:46:07 clang-s390x-linux | 04:30:33 clang-x86_64-linux-selfhost-modules| 03:44:26 llvm-clang-x86_64-expensive-checks-win | 03:38:38 llvm-hexagon-elf
