[Lldb-commits] [PATCH] D27085: [LLDB][MIPS] Fix TestMultipleHits for MIPS
nitesh.jain created this revision.
nitesh.jain added reviewers: labath, clayborg, zturner.
nitesh.jain added subscribers: jaydeep, bhushan, slthakur, lldb-commits.
https://reviews.llvm.org/D27085
Files:
packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_hits/main.cpp
Index:
packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_hits/main.cpp
===
---
packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_hits/main.cpp
+++
packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_hits/main.cpp
@@ -8,9 +8,7 @@
//===--===//
#include
#include
-
alignas(16) uint8_t buf[32];
-
// This uses inline assembly to generate an instruction that writes to a large
// block of memory. If it fails on your compiler/architecture, please add
// appropriate code to generate a large write to "buf". If you cannot write at
@@ -24,6 +22,8 @@
asm volatile ("stm %0, { r0, r1, r2, r3 }" : : "r"(buf));
#elif defined(__aarch64__)
asm volatile ("stp x0, x1, %0" : : "m"(buf));
+#elif defined(__mips__)
+ asm volatile ("lw $2, %0" : : "m"(buf));
#endif
return 0;
}
Index: packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_hits/main.cpp
===
--- packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_hits/main.cpp
+++ packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_hits/main.cpp
@@ -8,9 +8,7 @@
//===--===//
#include
#include
-
alignas(16) uint8_t buf[32];
-
// This uses inline assembly to generate an instruction that writes to a large
// block of memory. If it fails on your compiler/architecture, please add
// appropriate code to generate a large write to "buf". If you cannot write at
@@ -24,6 +22,8 @@
asm volatile ("stm %0, { r0, r1, r2, r3 }" : : "r"(buf));
#elif defined(__aarch64__)
asm volatile ("stp x0, x1, %0" : : "m"(buf));
+#elif defined(__mips__)
+ asm volatile ("lw $2, %0" : : "m"(buf));
#endif
return 0;
}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r287848 - Fix a comparison of integers of different signs warning.
Author: ttsugrii
Date: Wed Nov 23 19:34:43 2016
New Revision: 287848
URL: http://llvm.org/viewvc/llvm-project?rev=287848=rev
Log:
Fix a comparison of integers of different signs warning.
source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp:403:21:
warning: comparison of integers of different signs: 'int' and 'size_t' (aka
'unsigned long') [-Wsign-compare]
for (int i = 0; i < llvm::array_lengthof (magicks); i++)
~ ^ ~~
Differential Revision: https://reviews.llvm.org/D27081
Modified:
lldb/trunk/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
Modified:
lldb/trunk/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp?rev=287848=287847=287848=diff
==
---
lldb/trunk/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
(original)
+++
lldb/trunk/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
Wed Nov 23 19:34:43 2016
@@ -400,7 +400,7 @@ DynamicLoaderDarwinKernel::CheckForKerne
const uint32_t magicks[] = { llvm::MachO::MH_MAGIC_64,
llvm::MachO::MH_MAGIC, llvm::MachO::MH_CIGAM, llvm::MachO::MH_CIGAM_64};
bool found_matching_pattern = false;
- for (int i = 0; i < llvm::array_lengthof (magicks); i++)
+ for (size_t i = 0; i < llvm::array_lengthof (magicks); i++)
if (::memcmp (magicbuf, [i], sizeof (magicbuf)) == 0)
found_matching_pattern = true;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D27081: Fix a comparison of integers of different signs warning
inglorion accepted this revision. inglorion added a reviewer: inglorion. inglorion added a comment. This revision is now accepted and ready to land. lgtm https://reviews.llvm.org/D27081 ___ 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 11/13/2016 - 11/19/2016
Hello everyone, Below are some buildbot numbers for the last week of 11/13/2016 - 11/19/2016. 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-bootstrap | 66:29:59 clang-ppc64le-linux| 56:19:00 sanitizer-x86_64-linux-fast| 46:46:09 clang-s390x-linux | 41:17:45 sanitizer-ppc64be-linux| 39:19:54 sanitizer-ppc64le-linux| 38:08:34 lld-x86_64-darwin13| 38:06:50 clang-ppc64le-linux-lnt| 37:09:50 clang-ppc64be-linux-lnt| 37:06:00 clang-ppc64be-linux-multistage | 36:46:14 clang-x86_64-linux-selfhost-modules| 35:59:09 clang-ppc64le-linux-multistage | 35:45:04 clang-ppc64be-linux| 30:20:14 sanitizer-windows | 27:26:01 clang-cmake-mipsel | 20:53:28 clang-cmake-thumbv7-a15-full-sh| 15:29:50 perf-x86_64-penryn-O3-polly-before-vectorizer-detect-only | 13:01:30 lldb-windows7-android | 11:34:00 libcxx-libcxxabi-libunwind-arm-linux-noexceptions | 10:11:53 clang-cmake-mips | 08:09:26 libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11 | 07:55:32 sanitizer-x86_64-linux | 07:37:03 clang-x86-windows-msvc2015 | 07:17:16 clang-cmake-armv7-a15-selfhost-neon| 07:11:20 perf-x86_64-penryn-O3-polly-fast | 06:29:52 perf-x86_64-penryn-O3-polly-before-vectorizer | 06:24:07 clang-x64-ninja-win7 | 06:07:12 lldb-x86_64-ubuntu-14.04-buildserver | 05:37:48 lldb-amd64-ninja-netbsd7 | 05:17:22 lldb-x86_64-ubuntu-14.04-cmake | 04:52:56 clang-with-thin-lto-ubuntu | 04:38:51 lldb-amd64-ninja-freebsd11 | 04:37:51 clang-cmake-armv7-a15-selfhost | 04:16:25 clang-with-lto-ubuntu | 03:24:18 clang-cmake-thumbv7-a15| 03:15:26 clang-cmake-armv7-a15 | 03:13:57 clang-x86_64-debian-fast | 03:07:25 libcxx-libcxxabi-libunwind-x86_64-linux-debian | 02:57:08 llvm-mips-linux| 02:46:46 llvm-hexagon-elf | 02:40:59 clang-cmake-aarch64-full | 02:38:25 clang-cmake-aarch64-39vma | 02:32:50 clang-3stage-ubuntu| 02:20:06 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast | 02:18:40 libcxx-libcxxabi-x86_64-linux-debian | 02:12:57 sanitizer-x86_64-linux-fuzzer | 02:01:37 libcxx-libcxxabi-libunwind-arm-linux | 01:59:16 libcxx-libcxxabi-x86_64-linux-ubuntu-msan | 01:43:49 libcxx-libcxxabi-x86_64-linux-ubuntu-tsan | 01:43:40 clang-cmake-aarch64-quick | 01:43:00 libcxx-libcxxabi-x86_64-linux-ubuntu-asan | 01:39:22 libcxx-libcxxabi-x86_64-linux-ubuntu-ubsan | 01:35:04 clang-cmake-armv7-a15-full | 01:29:28 clang-native-arm-lnt | 01:29:14 clang-hexagon-elf | 01:25:00 perf-x86_64-penryn-O3-polly-parallel-fast | 01:22:52 lldb-x86_64-darwin-13.4| 01:22:00 lldb-x86-windows-msvc2015 | 01:18:57 clang-cmake-aarch64-42vma | 01:18:35
[Lldb-commits] [PATCH] D27017: Support more report types in AddressSanitizerRuntime.cpp
filcab added inline comments.
Comment at:
source/Plugins/InstrumentationRuntime/AddressSanitizer/AddressSanitizerRuntime.cpp:220
+ } else if (description == "stack-overflow") {
+return "Stack overflow detected (recursion too deep)";
+ } else if (description == "null-deref") {
kubabrecka wrote:
> filcab wrote:
> > Not necessarily recursion. There's also stack variables. I'd omit the stuff
> > in parenthesis.
> Multiple times have I seen that people read "stack overflow" as "stack
> **buffer** overflow" and they spend a lot of time trying to find what buffer
> was actually overflown... I'd like to somehow point that out. Ideas?
Maybe instead of "recursion too deep" have "stack space exhausted" or something
like that?
I've seen stack overflow errors on as few as 10 (maybe even fewer) stack frames
(with big objects). ASan is also more likely to make this a problem. I think
seeing "recursion too deep" but having only a dozen frames is probably
confusing.
Not that "stack space exhausted" is much better, but I think it's less likely
to be misleading.
And yes, please ask native speakers too, as I'm not one either. :-)
Repository:
rL LLVM
https://reviews.llvm.org/D27017
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D27017: Support more report types in AddressSanitizerRuntime.cpp
kubabrecka added a comment.
Thanks for these comments, I'll have them run by more people before committing
this (I'm not a native English speaker). These really need to be as
user-focused as possible, so I'm really against stuff like "not owned pointer",
because that's not something we should expect the user to understand. Also
note that we're not using these as a replacement of full reports, we're showing
them as a quick description in addition to ASan reports.
Comment at:
source/Plugins/InstrumentationRuntime/AddressSanitizer/AddressSanitizerRuntime.cpp:220
+ } else if (description == "stack-overflow") {
+return "Stack overflow detected (recursion too deep)";
+ } else if (description == "null-deref") {
filcab wrote:
> Not necessarily recursion. There's also stack variables. I'd omit the stuff
> in parenthesis.
Multiple times have I seen that people read "stack overflow" as "stack
**buffer** overflow" and they spend a lot of time trying to find what buffer
was actually overflown... I'd like to somehow point that out. Ideas?
Repository:
rL LLVM
https://reviews.llvm.org/D27017
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D27017: Support more report types in AddressSanitizerRuntime.cpp
filcab added a comment.
I have some minor fixes I'd like to see.
If it's prefixed by "Nit: " it's a really minor one and I'm ok with it as is if
that's what you prefer.
Thank you,
Filipe
Comment at:
source/Plugins/InstrumentationRuntime/AddressSanitizer/AddressSanitizerRuntime.cpp:220
+ } else if (description == "stack-overflow") {
+return "Stack overflow detected (recursion too deep)";
+ } else if (description == "null-deref") {
Not necessarily recursion. There's also stack variables. I'd omit the stuff in
parenthesis.
Comment at:
source/Plugins/InstrumentationRuntime/AddressSanitizer/AddressSanitizerRuntime.cpp:224
+ } else if (description == "wild-jump") {
+return "Wild pointer jump detected";
+ } else if (description == "wild-addr-write") {
Nit: "Wild jump" is probably better than "wild pointer jump", no?
Comment at:
source/Plugins/InstrumentationRuntime/AddressSanitizer/AddressSanitizerRuntime.cpp:226
+ } else if (description == "wild-addr-write") {
+return "Write to a wild pointer detected";
+ } else if (description == "wild-addr-read") {
Nit: I'd probably use "Write through wild pointer ..." (same for the others)
Comment at:
source/Plugins/InstrumentationRuntime/AddressSanitizer/AddressSanitizerRuntime.cpp:234
+ } else if (description == "double-free") {
+return "Attempt to deallocate a freed object detected";
+ } else if (description == "new-delete-type-mismatch") {
Nit: Phrasing seems off. I think "Double free detected" is easier to read and
more explicit.
Comment at:
source/Plugins/InstrumentationRuntime/AddressSanitizer/AddressSanitizerRuntime.cpp:236
+ } else if (description == "new-delete-type-mismatch") {
+return "Deallocation of a wrong size detected";
+ } else if (description == "bad-free") {
Nit: Maybe "Deallocation size mismatch detected"? The user isn't deallocating a
"size".
Comment at:
source/Plugins/InstrumentationRuntime/AddressSanitizer/AddressSanitizerRuntime.cpp:238
+ } else if (description == "bad-free") {
+return "Attempt to free a non-allocated address detected";
+ } else if (description == "alloc-dealloc-mismatch") {
s/address/memory region/?
Comment at:
source/Plugins/InstrumentationRuntime/AddressSanitizer/AddressSanitizerRuntime.cpp:242
+ } else if (description == "bad-malloc_usable_size") {
+return "Invalid call to malloc_usable_size detected";
+ } else if (description == "bad-__sanitizer_get_allocated_size") {
Maybe "Call to malloc_usable_size with not owned pointer detected"?
Unsure if it's obvious why it's "invalid". Same for the one below.
Comment at:
source/Plugins/InstrumentationRuntime/AddressSanitizer/AddressSanitizerRuntime.cpp:246
+ } else if (description == "param-overlap") {
+return "Overlapping memory ranges detected";
+ } else if (description == "negative-size-param") {
I think this really needs additional detail. It doesn't seem very meaningful as
a sentence.
Maybe "Overlapping memory ranges in function that doesn't allow them
(detected?)" or something?
My suggestion can be improved too, for sure :-)
Comment at:
source/Plugins/InstrumentationRuntime/AddressSanitizer/AddressSanitizerRuntime.cpp:250
+ } else if (description == "bad-__sanitizer_annotate_contiguous_container") {
+return "Invalid call to __sanitizer_annotate_contiguous_container
detected";
+ } else if (description == "odr-violation") {
Maybe "Invalid parameters to call to __sanitizer_annotate_contiguous_container"
is more explicit?
Maybe also a good solution for the similar cases above.
Comment at:
source/Plugins/InstrumentationRuntime/AddressSanitizer/AddressSanitizerRuntime.cpp:252
+ } else if (description == "odr-violation") {
+return "Initialization order problem detected";
+ } else if (description == "invalid-pointer-pair") {
"One Definition Rule violation"
It's not an initialization order problem.
Repository:
rL LLVM
https://reviews.llvm.org/D27017
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D26971: Introduce chrono to more gdb-remote functions
clayborg accepted this revision. clayborg added a comment. This revision is now accepted and ready to land. Much better, looks good. https://reviews.llvm.org/D26971 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D26676: Patch for lldb bug 26322 “core load hangs”
hhellyer added a comment. I'll land these changes tomorrow morning (UK time) so I can watch the builds and check there's no problems with the tests. https://reviews.llvm.org/D26676 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D26676: Patch for lldb bug 26322 “core load hangs”
hhellyer added a comment. I'll land these changes tomorrow morning (UK time) so I can watch the builds and check there's no problems with the tests. https://reviews.llvm.org/D26676 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D27010: Refactor LLDB's Windows process plugin (NFC)
labath accepted this revision. labath added a comment. This revision is now accepted and ready to land. seems reasonable. https://reviews.llvm.org/D27010 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D27017: Support more report types in AddressSanitizerRuntime.cpp
clayborg accepted this revision. clayborg added a comment. This revision is now accepted and ready to land. Looks fine. One question though: do we always have a shared library that contains the ASAN runtime? If so, then we can actually put the array of short to long description into the ASAN dylib and then we read this array as a global variable. This would allow you to add as many descriptions as you want directly in your ASAN code and have LLDB detect all of the new strings. Or, if there is a function you can call with the short description that returns the long description, then we can still have the ASAN code contain all of the strings. Repository: rL LLVM https://reviews.llvm.org/D27017 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D25947: Merge Linux and FreeBSD arm64 register contexts
labath added a comment. Ed, have you had a chance to try this out? I'd like to put this in soon. https://reviews.llvm.org/D25947 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D26676: Patch for lldb bug 26322 “core load hangs”
hhellyer updated this revision to Diff 79056.
hhellyer added a comment.
Updating patch to remove executables and create empty targets in the test cases.
https://reviews.llvm.org/D26676
Files:
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/gcore/
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/gcore/TestGCore.py
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/gcore/linux-i386.core
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/gcore/linux-x86_64.core
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/gcore/main.cpp
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/gcore/main.mk
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/gcore/make-core.sh
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/thread_crash/
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/thread_crash/TestLinuxCoreThreads.py
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/thread_crash/linux-i386.core
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/thread_crash/linux-x86_64.core
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/thread_crash/main.cpp
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/thread_crash/main.mk
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/thread_crash/make-core.sh
source/Plugins/Process/elf-core/ProcessElfCore.cpp
source/Plugins/Process/elf-core/ThreadElfCore.cpp
source/Plugins/Process/elf-core/ThreadElfCore.h
Index: source/Plugins/Process/elf-core/ThreadElfCore.h
===
--- source/Plugins/Process/elf-core/ThreadElfCore.h
+++ source/Plugins/Process/elf-core/ThreadElfCore.h
@@ -82,6 +82,38 @@
static_assert(sizeof(ELFLinuxPrStatus) == 112,
"sizeof ELFLinuxPrStatus is not correct!");
+struct ELFLinuxSigInfo {
+ int32_t si_signo;
+ int32_t si_code;
+ int32_t si_errno;
+
+ ELFLinuxSigInfo();
+
+ lldb_private::Error Parse(lldb_private::DataExtractor ,
+const lldb_private::ArchSpec );
+
+ // Return the bytesize of the structure
+ // 64 bit - just sizeof
+ // 32 bit - hardcoded because we are reusing the struct, but some of the
+ // members are smaller -
+ // so the layout is not the same
+ static size_t GetSize(const lldb_private::ArchSpec ) {
+switch (arch.GetCore()) {
+case lldb_private::ArchSpec::eCore_x86_64_x86_64:
+ return sizeof(ELFLinuxSigInfo);
+case lldb_private::ArchSpec::eCore_s390x_generic:
+case lldb_private::ArchSpec::eCore_x86_32_i386:
+case lldb_private::ArchSpec::eCore_x86_32_i486:
+ return 12;
+default:
+ return 0;
+}
+ }
+};
+
+static_assert(sizeof(ELFLinuxSigInfo) == 12,
+ "sizeof ELFLinuxSigInfo is not correct!");
+
// PRPSINFO structure's size differs based on architecture.
// This is the layout in the x86-64 arch case.
// In the i386 case we parse it manually and fill it again
@@ -133,7 +165,8 @@
lldb_private::DataExtractor fpregset;
lldb_private::DataExtractor vregset;
lldb::tid_t tid;
- int signo;
+ int signo = 0;
+ int prstatus_sig = 0;
std::string name;
};
Index: source/Plugins/Process/elf-core/ThreadElfCore.cpp
===
--- source/Plugins/Process/elf-core/ThreadElfCore.cpp
+++ source/Plugins/Process/elf-core/ThreadElfCore.cpp
@@ -320,3 +320,45 @@
return error;
}
+
+//
+// Parse SIGINFO from NOTE entry
+//
+ELFLinuxSigInfo::ELFLinuxSigInfo() {
+ memset(this, 0, sizeof(ELFLinuxSigInfo));
+}
+
+Error ELFLinuxSigInfo::Parse(DataExtractor , const ArchSpec ) {
+ Error error;
+ ByteOrder byteorder = data.GetByteOrder();
+ if (GetSize(arch) > data.GetByteSize()) {
+error.SetErrorStringWithFormat(
+"NT_SIGINFO size should be %zu, but the remaining bytes are: %" PRIu64,
+GetSize(arch), data.GetByteSize());
+return error;
+ }
+
+ switch (arch.GetCore()) {
+ case ArchSpec::eCore_x86_64_x86_64:
+data.ExtractBytes(0, sizeof(ELFLinuxPrStatus), byteorder, this);
+break;
+ case ArchSpec::eCore_s390x_generic:
+ case ArchSpec::eCore_x86_32_i386:
+ case ArchSpec::eCore_x86_32_i486: {
+// Parsing from a 32 bit ELF core file, and populating/reusing the structure
+// properly, because the struct is for the 64 bit version
+offset_t offset = 0;
+si_signo = data.GetU32();
+si_code = data.GetU32();
+si_errno = data.GetU32();
+
+break;
+ }
+ default:
+error.SetErrorStringWithFormat("ELFLinuxSigInfo::%s Unknown architecture",
+ __FUNCTION__);
+break;
+ }
+
+ return error;
+}
Index:
[Lldb-commits] [PATCH] D26676: Patch for lldb bug 26322 “core load hangs”
labath added a comment.
I just tried it, and these tests run fine without the executable file. Just
remove those, and I think we're ready.
Comment at:
packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/gcore/TestGCore.py:38
+def do_test(self, filename, pid):
+target = self.dbg.CreateTarget(filename + ".out")
+process = target.LoadCore(filename + ".core")
You don't need the executable file for this test. Just create an empty target
`self.dbg.CreateTarget("")` and use that.
https://reviews.llvm.org/D26676
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D26676: Patch for lldb bug 26322 “core load hangs”
hhellyer added a comment. @labath If you are happy with the tests and the size of their supporting files I'll land this, otherwise let me know if anything needs changing. https://reviews.llvm.org/D26676 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D26971: Introduce chrono to more gdb-remote functions
labath updated this revision to Diff 79050.
labath added a comment.
Changes since last version:
- Rename the class to Timeout<>, to reflect the fact that I'd like to use it as
a general method for describing timeouts.
- add "using namespace std::chrono" to files with significat chrono usage.
I did not use chrono literals, as those are a c++14 feature. I don't think that
matters much as thanks to the previous import, something like seconds(X) is
quite
short already.
Let me know what you think.
https://reviews.llvm.org/D26971
Files:
source/Plugins/Process/gdb-remote/GDBRemoteClientBase.cpp
source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
source/Plugins/Process/gdb-remote/GDBRemoteCommunication.h
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.h
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
tools/lldb-server/lldb-platform.cpp
Index: tools/lldb-server/lldb-platform.cpp
===
--- tools/lldb-server/lldb-platform.cpp
+++ tools/lldb-server/lldb-platform.cpp
@@ -364,7 +364,7 @@
bool interrupt = false;
bool done = false;
while (!interrupt && !done) {
- if (platform.GetPacketAndSendResponse(UINT32_MAX, error, interrupt,
+ if (platform.GetPacketAndSendResponse(llvm::None, error, interrupt,
done) !=
GDBRemoteCommunication::PacketResult::Success)
break;
Index: source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
===
--- source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++ source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
@@ -926,8 +926,8 @@
bool done = false;
Error error;
while (true) {
-const PacketResult result =
-GetPacketAndSendResponse(0, error, interrupt, done);
+const PacketResult result = GetPacketAndSendResponse(
+std::chrono::microseconds(0), error, interrupt, done);
if (result == PacketResult::ErrorReplyTimeout)
break; // No more packets in the queue
Index: source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.h
===
--- source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.h
+++ source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.h
@@ -43,8 +43,9 @@
RegisterPacketHandler(StringExtractorGDBRemote::ServerPacketType packet_type,
PacketHandler handler);
- PacketResult GetPacketAndSendResponse(uint32_t timeout_usec, Error ,
-bool , bool );
+ PacketResult GetPacketAndSendResponse(Timeout timeout,
+Error , bool ,
+bool );
// After connecting, do a little handshake with the client to make sure
// we are at least communicating
Index: source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
===
--- source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
+++ source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
@@ -38,14 +38,11 @@
}
GDBRemoteCommunication::PacketResult
-GDBRemoteCommunicationServer::GetPacketAndSendResponse(uint32_t timeout_usec,
- Error ,
- bool ,
- bool ) {
+GDBRemoteCommunicationServer::GetPacketAndSendResponse(
+Timeout timeout, Error , bool , bool ) {
StringExtractorGDBRemote packet;
- PacketResult packet_result =
- WaitForPacketWithTimeoutMicroSecondsNoLock(packet, timeout_usec, false);
+ PacketResult packet_result = WaitForPacketNoLock(packet, timeout, false);
if (packet_result == PacketResult::Success) {
const StringExtractorGDBRemote::ServerPacketType packet_type =
packet.GetServerPacketType();
Index: source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
===
--- source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
+++ source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
@@ -49,6 +49,7 @@
using namespace lldb;
using namespace lldb_private;
using namespace lldb_private::process_gdb_remote;
+using namespace std::chrono;
//--
// GDBRemoteCommunicationClient constructor
@@ -122,9 +123,8 @@
// GDB server and flush them all
StringExtractorGDBRemote response;
PacketResult packet_result = PacketResult::Success;
-
