[Lldb-commits] [PATCH] D32732: "target variable" not showing all global variable if we print any global variable before execution starts
vbalu added a comment.
i am confused as I dont see it is similar way when i don't print global
variable before strting inferior.
For the c file "lldbsuite/test/functionalities/target_command/globals.c" i see
"target variable" behaves differently as below.
**Without printing global variable before starting inferior:**
(lldb) target create "global"
Current executable set to 'global' (x86_64).
(lldb) b main
Breakpoint 1: where = global`main + 30 at globals.c:18, address =
0x0040074e
(lldb) r
Process 37645 launching
Process 37645 launched: '/b/vignesh/lldb_temp/global' (x86_64)
Process 37645 stopped
* thread #1, name = 'global', stop reason = breakpoint 1.1
frame #0: 0x0040074e global`main(argc=1, argv=0x7fffe9d0)
at globals.c:18
15
16 int main (int argc, char const *argv[])
17 {
-> 18 int a =0;
19 int b =0;
20
21 printf("global char: %c\n", my_global_char);
(lldb) target variable
Global variables for /b/vignesh/lldb_temp/globals.c in
/b/vignesh/lldb_temp/global:
(char) my_global_char = 'X'
(const char *) my_global_str = 0x00400806 "abc"
(const char **) my_global_str_ptr = 0x00600af0
(int) my_static_int = 228
(lldb)
**With printing global variable before starting inferior**
(lldb) target create "global"
Current executable set to 'global' (x86_64).
(lldb) target variable my_global_char
(char) my_global_char = 'X'
(lldb) b main
Breakpoint 1: where = global`main + 30 at globals.c:18, address =
0x0040074e
(lldb) r
Process 37681 launching
Process 37681 launched: '/b/vignesh/lldb_temp/global' (x86_64)
Process 37681 stopped
* thread #1, name = 'global', stop reason = breakpoint 1.1
frame #0: 0x0040074e global`main(argc=1, argv=0x7fffe9d0)
at globals.c:18
15
16 int main (int argc, char const *argv[])
17 {
-> 18 int a =0;
19 int b =0;
20
21 printf("global char: %c\n", my_global_char);
lldb) target variable
Global variables for /b/vignesh/lldb_temp/globals.c in
/b/vignesh/lldb_temp/global:
(char) my_global_char = 'X'
(lldb)
Please let me know if above change in behavior is expected. If so Please
explain.
Repository:
rL LLVM
https://reviews.llvm.org/D32732
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32753: MainLoop: Add unit tests
eugene accepted this revision.
eugene added inline comments.
This revision is now accepted and ready to land.
Comment at: source/Host/common/MainLoop.cpp:66
class MainLoop::RunImpl {
public:
Could you please add here a comment describing when kqueue/pselect/ppoll are
used.
https://reviews.llvm.org/D32753
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32787: Fix build error: no viable conversion from returned value of type 'int' to function return type 'sigset_t' (aka '__sigset_t')
xiangzhai abandoned this revision. xiangzhai added a comment. > Opening the CMakeCache.txt, and deleting the HAVE_PPOLL line should > re-trigger the detection Fixed! Repository: rL LLVM https://reviews.llvm.org/D32787 ___ 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 last week of 04/23/2017 - 04/29/2017
Hello everyone, Below are some buildbot numbers for the last week of 04/23/2017 - 04/29/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 +- perf-x86_64-penryn-O3-polly-before-vectorizer-unprofitable | 90:36:06 perf-x86_64-penryn-O3-polly-before-vectorizer | 85:44:16 clang-ppc64le-linux| 82:51:20 perf-x86_64-penryn-O3-polly-before-vectorizer-detect-only | 78:40:55 perf-x86_64-penryn-O3 | 78:15:31 perf-x86_64-penryn-O3-polly| 77:57:26 perf-x86_64-penryn-O3-polly-unprofitable | 72:27:03 perf-x86_64-penryn-O3-polly-parallel-fast | 71:43:02 perf-x86_64-penryn-O3-polly-fast | 71:27:28 llvm-sphinx-docs | 68:46:18 sanitizer-x86_64-linux-bootstrap | 66:29:20 sanitizer-x86_64-linux-fast| 65:10:37 clang-x64-ninja-win7 | 41:25:42 sanitizer-windows | 40:23:19 clang-cmake-mips | 35:39:36 llvm-mips-linux| 35:03:04 lldb-x86_64-darwin-13.4| 34:16:09 lldb-x86_64-ubuntu-14.04-android | 22:40:51 clang-ppc64le-linux-multistage | 21:20:10 lldb-windows7-android | 20:54:19 lld-x86_64-win7| 19:37:00 lldb-amd64-ninja-netbsd8 | 12:42:03 clang-ppc64be-linux-lnt| 07:59:17 lldb-x86_64-ubuntu-14.04-buildserver | 07:59:09 lldb-amd64-ninja-netbsd7 | 07:58:45 lldb-x86_64-ubuntu-14.04-cmake | 07:52:33 lldb-amd64-ninja-freebsd11 | 07:33:07 lldb-x86-windows-msvc2015 | 07:31:29 sanitizer-x86_64-linux-autoconf| 07:25:11 clang-cmake-aarch64-full | 07:16:08 clang-lld-x86_64-2stage| 07:01:14 clang-with-thin-lto-ubuntu | 06:56:02 clang-cmake-aarch64-lld| 06:53:01 clang-cmake-thumbv7-a15-full-sh| 06:48:31 sanitizer-ppc64le-linux| 06:43:29 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast | 06:36:29 llvm-clang-x86_64-expensive-checks-win | 06:36:10 clang-with-lto-ubuntu | 06:35:19 clang-ppc64be-linux-multistage | 06:30:18 clang-x86-windows-msvc2015 | 06:28:03 sanitizer-ppc64be-linux| 06:25:18 sanitizer-x86_64-linux | 06:21:59 clang-cmake-armv7-a15-selfhost | 06:07:09 clang-bpf-build| 05:46:46 clang-x86_64-linux-selfhost-modules-2 | 05:42:12 clang-x86_64-linux-selfhost-modules| 05:32:30 clang-cmake-armv7-a15-selfhost-neon| 05:27:08 clang-cmake-aarch64-39vma | 04:46:34 clang-cmake-aarch64-quick | 04:36:55 clang-cmake-armv7-a15-full | 04:21:24 lld-x86_64-darwin13| 04:19:08 clang-cmake-armv7-a15 | 04:05:58 clang-cmake-thumbv7-a15| 04:02:11 polly-amd64-linux | 03:39:37 llvm-hexagon-elf | 03:36:37 sanitizer-x86_64-linux-fuzzer | 03:36:07 clang-x86_64-debian-fast | 03:27:30 clang-atom-d525-fedora-rel | 02:58:30 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast | 02:35:24 clang-cmake-aarch64-42vm
[Lldb-commits] Buildbot numbers for the week of 04/16/2017 - 04/22/2017
Hello everyone, Below are some buildbot numbers for the week of 04/16/2017 - 04/22/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-bpf-build | 85:32:13 sanitizer-x86_64-linux-fast | 84:09:54 sanitizer-x86_64-linux| 81:57:21 clang-with-thin-lto-ubuntu| 43:24:00 sanitizer-x86_64-linux-bootstrap | 31:46:53 clang-cmake-aarch64-lld | 24:25:40 lldb-x86_64-ubuntu-14.04-cmake| 14:36:10 libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11 | 10:50:18 clang-cmake-armv7-a15-full| 10:25:50 clang-cmake-thumbv7-a15-full-sh | 09:21:40 clang-cmake-mips | 08:59:44 lldb-x86_64-ubuntu-14.04-android | 07:31:30 libcxx-libcxxabi-x86_64-linux-ubuntu-msan | 07:04:17 clang-cmake-aarch64-39vma | 06:37:21 clang-x86_64-debian-fast | 06:30:25 sanitizer-ppc64le-linux | 06:16:28 clang-cmake-aarch64-42vma | 06:14:41 clang-lld-x86_64-2stage | 05:41:49 clang-x64-ninja-win7 | 05:35:42 clang-x86-windows-msvc2015| 05:17:16 lldb-x86-windows-msvc2015 | 05:16:38 clang-ppc64le-linux-multistage| 05:11:56 clang-cmake-mipsel| 04:45:30 lldb-windows7-android | 04:31:53 clang-s390x-linux | 04:16:23 llvm-clang-x86_64-expensive-checks-win| 04:14:34 clang-ppc64be-linux-multistage| 03:56:50 clang-ppc64le-linux | 03:50:14 clang-ppc64be-linux-lnt | 03:46:14 clang-ppc64be-linux | 03:44:09 sanitizer-ppc64be-linux | 03:40:31 clang-with-lto-ubuntu | 03:39:34 clang-cmake-armv7-a15-selfhost-neon | 03:36:01 clang-cmake-armv7-a15-selfhost| 03:31:07 clang-cmake-aarch64-full | 03:27:41 llvm-mips-linux | 03:19:19 libcxx-libcxxabi-libunwind-aarch64-linux-noexceptions | 03:17:58 clang-x86_64-linux-selfhost-modules-2 | 03:09:15 polly-amd64-linux | 03:07:58 sanitizer-windows | 02:52:25 sanitizer-x86_64-linux-autoconf | 02:42:44 perf-x86_64-penryn-O3-polly-parallel-fast | 02:42:44 libcxx-libcxxabi-x86_64-linux-ubuntu-asan | 02:37:00 lldb-x86_64-ubuntu-14.04-buildserver | 02:31:12 perf-x86_64-penryn-O3-polly-unprofitable | 02:28:52 lldb-amd64-ninja-netbsd7 | 02:21:44 clang-cmake-armv7-a15 | 02:14:49 clang-cmake-thumbv7-a15 | 02:12:20 clang-hexagon-elf | 02:09:28 clang-cmake-aarch64-quick | 02:08:29 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast | 02:04:48 libcxx-libcxxabi-x86_64-linux-debian | 01:51:17 lldb-x86_64-darwin-13.4 | 01:39:01 clang-atom-d525-fedora-rel| 01:36:17 clang-ppc64le-linux-lnt | 01:32:13 clang-native-arm-lnt | 01:32:08 libcxx-libcxxabi-libunwind-arm-linux | 01:30:47 polly-arm-linux | 01:29:59 sanitizer-x86_64-linux-fuzzer | 01:28:25 clang-x86_64-linux-selfhost-modules | 01:25:35 libcxx-libcxxabi-libunwind-arm-linux-noexceptions | 01:16:44 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx1z| 01:15:22 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03| 01:06:35 lld-x86_64-darwin13 | 00:58:54 libc
[Lldb-commits] [PATCH] D32832: Make ConstString creation and access lockfree
scott.smith added a comment. In https://reviews.llvm.org/D32832#745361, @clayborg wrote: > Do you have performance numbers here? I am all for it if it improves > performance. If this is faster than llvm::StringMap why not just fix it > there? Seems like everyone could benefit if you fix it in LLVM? A proper lockfree hashtable that allows deletions is complicated and slow for simple cases, IME. ConstString is a special case, because 1. It's big 2. It's insert-only 3. It's highly concurrent I think a proper lock free SkipList would be a better fit for LLVM though, and this code could then build upon it, which would solve it's existing scalability issue. Truth is this isn't a huge deal (ignoring the HashString->xxHash change and assuming tcmalloc, it's saving 1+ seconds, out of 4.5-5ish). It might lead itself to a custom allocator, though, which may make linking with tcmalloc unnecessary (something like BumpPtrAllocator, but threadsafe, or maybe just thread local). Again, a trick you can get away with since this is insert-only. So to break it down: 1. the HashString->xxHash change could be made separately if there was a version of StringMap that took the hash as a parameter, rather than running the hash function itself. That would reduce the # of calls from 2 to 1, and would allow the use of a function that is better suited to lldb (I ran into resistance changing llvm::HashString since clang depends on it, and I couldn't prove it wouldn't hurt. 2. 64-bit hashes for fewer collisions - StringMap uses 32-bit hashes, which makes sense for smaller hash tables. This may or may not matter much. 3. no lock for reading or updating value - GetMangledCounterpart, SetMangledCounterparts, and half of GetConstCStringAndSetMangledCountrpart no longer compute a hash, and don't need a lock. You can actually do this with StringMap by using a struct as the value side that has std::atomic in it 4. much finer granularity - I tried increasing the # of buckets in the old ConstString but could never improve performance (though that was without tcmalloc, maybe it'd work now) 5. lockfree insertion and possibly in the future: 6. BumpPtrAllocator for struct Entry - maybe eliminate the need for tcmalloc (well, assuming the demangler used an arena allocator, something else I gave up rather than trying to convince libcxxabi to change, then having to port that back to llvm). I haven't measured how much each of these changes matter. This change is small enough and in a file that changes infrequently, so we can keep this as a private patch if we have to. Repository: rL LLVM https://reviews.llvm.org/D32832 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D32832: Make ConstString creation and access lockfree
It isn't uncommon for folks to debug programs with all the debug information for the whole system available. In those cases, what looks to the user like a normal sized application is actually a very large one as far as lldb's global string pool is concerned. My experience is that whenever you say "size of debug information"/"number of symbols" won't get larger than X, not very much time will generally show you wrong. So I'm leery of this change. Jim > On May 3, 2017, at 3:04 PM, Scott Smith via Phabricator via lldb-commits > wrote: > > scott.smith added a comment. > > Note, I don't expect you guys to want this as is, since the # of buckets > can't grow, and thus for very large applications this will behave O(n) > instead of O(1). Before I bother to convert this to 1M skip lists (instead > of 1M singly linked lists), is this something you're at all interested in? > It brings execution time of my test down from ~4.5s to ~3.5s (lldb -b -o 'b > main' -o 'run' my_test_program). > > > Repository: > rL LLVM > > https://reviews.llvm.org/D32832 > > > > ___ > 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] D32832: Make ConstString creation and access lockfree
clayborg added a comment. Sorry missed your first note about perf. This has to be able to handle any number of strings efficiently and growing buckets is probably needed. How many buckets are you starting with here? The design probably shouldn't take up gobs of memory if it just has a few strings as well. Do we really need to use a homegrown hash table here? Can we not leverage std::unordered_map or some other hash table in LLVM here? Repository: rL LLVM https://reviews.llvm.org/D32832 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32832: Make ConstString creation and access lockfree
clayborg added a comment. Do you have performance numbers here? I am all for it if it improves performance. If this is faster than llvm::StringMap why not just fix it there? Seems like everyone could benefit if you fix it in LLVM? Repository: rL LLVM https://reviews.llvm.org/D32832 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32832: Make ConstString creation and access lockfree
scott.smith added a comment. Note, I don't expect you guys to want this as is, since the # of buckets can't grow, and thus for very large applications this will behave O(n) instead of O(1). Before I bother to convert this to 1M skip lists (instead of 1M singly linked lists), is this something you're at all interested in? It brings execution time of my test down from ~4.5s to ~3.5s (lldb -b -o 'b main' -o 'run' my_test_program). Repository: rL LLVM https://reviews.llvm.org/D32832 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32832: Make ConstString creation and access lockfree
scott.smith created this revision.
Utilize atomics to update linked lists without requiring locks. Reduces the
number of calls to compute the hash by not having to compute it once to
determine the bucket and then again inside a separate hashtable implementation.
Use xxhash for better performance, especially with longer strings. Eliminates
calls to hash when just updating the value by being able to use atomics instead
of locks.
Repository:
rL LLVM
https://reviews.llvm.org/D32832
Files:
source/Utility/ConstString.cpp
Index: source/Utility/ConstString.cpp
===
--- source/Utility/ConstString.cpp
+++ source/Utility/ConstString.cpp
@@ -18,6 +18,7 @@
#include "llvm/Support/FormatProviders.h" // for format_provider
#include "llvm/Support/RWMutex.h"
#include "llvm/Support/Threading.h"
+#include "llvm/Support/xxhash.h"
#include // for min
#include
@@ -31,47 +32,58 @@
class Pool {
public:
- typedef const char *StringPoolValueType;
- typedef llvm::StringMap
- StringPool;
- typedef llvm::StringMapEntry StringPoolEntryType;
+ struct Entry {
+uint64_t hash;
+size_t key_len;
+std::atomic value;
+std::atomic next;
+// string follows
+void setValue(const char * val) {
+ value.store(val, std::memory_order_release);
+}
+const char * cstr() const {
+ return reinterpret_cast(this + 1);
+}
+llvm::StringRef str() const {
+ return llvm::StringRef(cstr(), key_len);
+}
+ };
+
+ Pool() {
+for (auto & a : m_string_pools)
+ a.store(nullptr, std::memory_order_release);
+ }
+
+ typedef std::atomic StringPool;
+ typedef Entry StringPoolEntryType;
static StringPoolEntryType &
GetStringMapEntryFromKeyData(const char *keyData) {
-return StringPoolEntryType::GetStringMapEntryFromKeyData(keyData);
+StringPoolEntryType * p = reinterpret_cast(const_cast(keyData));
+return *(p - 1);
}
static size_t GetConstCStringLength(const char *ccstr) {
if (ccstr != nullptr) {
// Since the entry is read only, and we derive the entry entirely from the
// pointer, we don't need the lock.
const StringPoolEntryType &entry = GetStringMapEntryFromKeyData(ccstr);
- return entry.getKey().size();
+ return entry.key_len;
}
return 0;
}
- StringPoolValueType GetMangledCounterpart(const char *ccstr) const {
+ const char * GetMangledCounterpart(const char *ccstr) const {
if (ccstr != nullptr) {
- const uint8_t h = hash(llvm::StringRef(ccstr));
- llvm::sys::SmartScopedReader rlock(m_string_pools[h].m_mutex);
- return GetStringMapEntryFromKeyData(ccstr).getValue();
+ return GetStringMapEntryFromKeyData(ccstr).value;
}
return nullptr;
}
bool SetMangledCounterparts(const char *key_ccstr, const char *value_ccstr) {
if (key_ccstr != nullptr && value_ccstr != nullptr) {
- {
-const uint8_t h = hash(llvm::StringRef(key_ccstr));
-llvm::sys::SmartScopedWriter wlock(m_string_pools[h].m_mutex);
-GetStringMapEntryFromKeyData(key_ccstr).setValue(value_ccstr);
- }
- {
-const uint8_t h = hash(llvm::StringRef(value_ccstr));
-llvm::sys::SmartScopedWriter wlock(m_string_pools[h].m_mutex);
-GetStringMapEntryFromKeyData(value_ccstr).setValue(key_ccstr);
- }
+ GetStringMapEntryFromKeyData(key_ccstr).setValue(value_ccstr);
+ GetStringMapEntryFromKeyData(value_ccstr).setValue(key_ccstr);
return true;
}
return false;
@@ -91,53 +103,50 @@
const char *GetConstCStringWithStringRef(const llvm::StringRef &string_ref) {
if (string_ref.data()) {
- const uint8_t h = hash(string_ref);
-
- {
-llvm::sys::SmartScopedReader rlock(m_string_pools[h].m_mutex);
-auto it = m_string_pools[h].m_string_map.find(string_ref);
-if (it != m_string_pools[h].m_string_map.end())
- return it->getKeyData();
+ const uint64_t h = hash(string_ref);
+ while (true) {
+auto * b = &bucket(h);
+Entry * bref;
+while ((bref = b->load())) {
+ if (bref->hash > h)
+break;
+ if (bref->hash == h) {
+// Hash collision, do a secondary sort on string
+llvm::StringRef bstringref = bref->str();
+if (string_ref == bstringref)
+ return bref->cstr();
+if (bstringref > string_ref)
+ break;
+ }
+ b = &bref->next;
+}
+Entry * new_entry = reinterpret_cast(
+ malloc(sizeof(Entry) + string_ref.size() + 1));
+new_entry->hash = h;
+new_entry->key_len = string_ref.size();
+new_entry->value.store(nullptr, std::memory_order_relaxed);
+new_entry->next.store(bref, std::memory_order_relaxed);
+char * dest = const_cast(new_entry->cstr());
+memcpy(dest, string_ref.data(), string_ref.size());
+
[Lldb-commits] [PATCH] D32787: Fix build error: no viable conversion from returned value of type 'int' to function return type 'sigset_t' (aka '__sigset_t')
probinson added a comment. In https://reviews.llvm.org/D32787#745205, @labath wrote: > In https://reviews.llvm.org/D32787#745139, @probinson wrote: > > > In https://reviews.llvm.org/D32787#745099, @labath wrote: > > > > > Could it be that you just have stale cmake cache? > > > > > > That could easily be true. Rerunning cmake didn't fix it; short of > > deleting the entire build directory, is there a way to refresh the cache? > > > Opening the CMakeCache.txt, and deleting the HAVE_PPOLL line should > re-trigger the detection. But if that doesn't fix it, I'd certainly recommend > nuking the build directory before looking for problems elsewhere. Yes, that worked. Which leaves the original source-text problem, of course, but at least I'm not having to maintain a local patch anymore. Thanks! Repository: rL LLVM https://reviews.llvm.org/D32787 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32597: Initiate loading of shared libraries in parallel
zturner added a comment. https://reviews.llvm.org/D32826 Repository: rL LLVM https://reviews.llvm.org/D32597 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32421: Fix segfault resulting from empty print prompt
xiaobai updated this revision to Diff 97717.
xiaobai added a comment.
Moving test per @labath's suggestion
https://reviews.llvm.org/D32421
Files:
packages/Python/lldbsuite/test/expression_command/multiline/TestMultilineExpressions.py
source/Host/common/Editline.cpp
Index: source/Host/common/Editline.cpp
===
--- source/Host/common/Editline.cpp
+++ source/Host/common/Editline.cpp
@@ -367,7 +367,7 @@
if (to == CursorLocation::EditingCursor) {
toColumn =
editline_cursor_position - (editline_cursor_row * m_terminal_width) +
1;
- } else if (to == CursorLocation::BlockEnd) {
+ } else if (to == CursorLocation::BlockEnd && !m_input_lines.empty()) {
toColumn =
((m_input_lines[m_input_lines.size() - 1].length() + GetPromptWidth())
%
80) +
Index:
packages/Python/lldbsuite/test/expression_command/multiline/TestMultilineExpressions.py
===
---
packages/Python/lldbsuite/test/expression_command/multiline/TestMultilineExpressions.py
+++
packages/Python/lldbsuite/test/expression_command/multiline/TestMultilineExpressions.py
@@ -60,3 +60,25 @@
child.expect_exact(prompt)
self.expect(child.before, exe=False,
patterns=['= 5'])
+
+def test_empty_list(self):
+"""Test printing an empty list of expressions"""
+import pexpect
+prompt = "(lldb) "
+
+# So that the child gets torn down after the test
+self.child = pexpect.spawn(
+"%s %s" %
+(lldbtest_config.lldbExec, self.lldbOption))
+child = self.child
+
+# Turn on logging for what the child sends back.
+if self.TraceOn():
+child.logfile_read = sys.stdout
+
+# We expect a prompt, then send "print" to start a list of
expressions,
+# then an empty line. We expect a prompt back.
+child.expect_exact(prompt)
+child.sendline("print")
+child.sendline("\n")
+child.expect_exact(prompt)
Index: source/Host/common/Editline.cpp
===
--- source/Host/common/Editline.cpp
+++ source/Host/common/Editline.cpp
@@ -367,7 +367,7 @@
if (to == CursorLocation::EditingCursor) {
toColumn =
editline_cursor_position - (editline_cursor_row * m_terminal_width) + 1;
- } else if (to == CursorLocation::BlockEnd) {
+ } else if (to == CursorLocation::BlockEnd && !m_input_lines.empty()) {
toColumn =
((m_input_lines[m_input_lines.size() - 1].length() + GetPromptWidth()) %
80) +
Index: packages/Python/lldbsuite/test/expression_command/multiline/TestMultilineExpressions.py
===
--- packages/Python/lldbsuite/test/expression_command/multiline/TestMultilineExpressions.py
+++ packages/Python/lldbsuite/test/expression_command/multiline/TestMultilineExpressions.py
@@ -60,3 +60,25 @@
child.expect_exact(prompt)
self.expect(child.before, exe=False,
patterns=['= 5'])
+
+def test_empty_list(self):
+"""Test printing an empty list of expressions"""
+import pexpect
+prompt = "(lldb) "
+
+# So that the child gets torn down after the test
+self.child = pexpect.spawn(
+"%s %s" %
+(lldbtest_config.lldbExec, self.lldbOption))
+child = self.child
+
+# Turn on logging for what the child sends back.
+if self.TraceOn():
+child.logfile_read = sys.stdout
+
+# We expect a prompt, then send "print" to start a list of expressions,
+# then an empty line. We expect a prompt back.
+child.expect_exact(prompt)
+child.sendline("print")
+child.sendline("\n")
+child.expect_exact(prompt)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32787: Fix build error: no viable conversion from returned value of type 'int' to function return type 'sigset_t' (aka '__sigset_t')
labath added a comment. In https://reviews.llvm.org/D32787#745139, @probinson wrote: > In https://reviews.llvm.org/D32787#745099, @labath wrote: > > > Could it be that you just have stale cmake cache? > > > That could easily be true. Rerunning cmake didn't fix it; short of deleting > the entire build directory, is there a way to refresh the cache? Opening the CMakeCache.txt, and deleting the HAVE_PPOLL line should re-trigger the detection. But if that doesn't fix it, I'd certainly recommend nuking the build directory before looking for problems elsewhere. Repository: rL LLVM https://reviews.llvm.org/D32787 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32597: Initiate loading of shared libraries in parallel
zturner added inline comments.
Comment at:
source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp:530-560
+ struct loader {
+DYLDRendezvous::iterator I;
+ModuleSP m;
+std::shared_future f;
+ };
+ std::vector loaders(num_to_load);
+ llvm::ThreadPool load_pool(
scott.smith wrote:
> zturner wrote:
> > zturner wrote:
> > > I'm still unclear why we're still going down this route of adding a very
> > > specialized instance of parallelism to this one place, that is probably
> > > going to be less efficient than having a global thread pool (as now you
> > > will have to spin up and destroy the entire thread pool every time you go
> > > to load shared libraries).
> > >
> > > So, rather than keep repeating the same thing over and over, I went and
> > > looked into this a little bit. It turns out LLD has a large library of
> > > parallel algorithms in `lld/Include/lld/Parallel.h`. There is almost
> > > nothing specific to LLD in any of these algorithms however, and they
> > > should probably be moved to llvm support. Upon doing so, you will be
> > > able to write this code as:
> > >
> > > ```
> > > std::vector Modules(m_rendevous.size());
> > > llvm::parallel_for_each(make_integer_range(0, m_rendevous.size()), [this,
> > > &Modules](int I)
> > > {
> > > auto &R = m_rendevous[I];
> > > Modules[I] = LoadModuleAtAddress(R.file_spec, R.link_addr,
> > > R.base_addr, true);
> > > });
> > > for (const auto &M : Modules)
> > >module_list.Append(M);
> > > ```
> > >
> > > Please look into making this change.
> > Note that this is, of course, exactly why I've been saying all along that
> > we should not even be discussing this here. Had the discussion happened
> > over on the LLVM side the first time I asked about this, someone could have
> > mentioned this without me having to spend time looking into it.
> As long as those routines allow you to recursively call those routines, then
> great, go for it.
>
> The spinning up/tearing down of threads is not expensive, at least in my
> measured use case.
> As long as those routines allow you to recursively call those routines, then
> great, go for it.
Right, which is why I've asked at least 4 times for it to be looked into. That
doesn't mean mean use the first thing you see and check it in right away, it
means please see if there is some way to use existing code to solve the
problem. If it turns out this doesn't allow recursive use, then a followup
would be to understand why not, and if it is hard to change.
So again, please look into this and see if it will work for your needs.
Repository:
rL LLVM
https://reviews.llvm.org/D32597
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32597: Initiate loading of shared libraries in parallel
scott.smith added inline comments.
Comment at:
source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp:530-560
+ struct loader {
+DYLDRendezvous::iterator I;
+ModuleSP m;
+std::shared_future f;
+ };
+ std::vector loaders(num_to_load);
+ llvm::ThreadPool load_pool(
zturner wrote:
> zturner wrote:
> > I'm still unclear why we're still going down this route of adding a very
> > specialized instance of parallelism to this one place, that is probably
> > going to be less efficient than having a global thread pool (as now you
> > will have to spin up and destroy the entire thread pool every time you go
> > to load shared libraries).
> >
> > So, rather than keep repeating the same thing over and over, I went and
> > looked into this a little bit. It turns out LLD has a large library of
> > parallel algorithms in `lld/Include/lld/Parallel.h`. There is almost
> > nothing specific to LLD in any of these algorithms however, and they should
> > probably be moved to llvm support. Upon doing so, you will be able to
> > write this code as:
> >
> > ```
> > std::vector Modules(m_rendevous.size());
> > llvm::parallel_for_each(make_integer_range(0, m_rendevous.size()), [this,
> > &Modules](int I)
> > {
> > auto &R = m_rendevous[I];
> > Modules[I] = LoadModuleAtAddress(R.file_spec, R.link_addr, R.base_addr,
> > true);
> > });
> > for (const auto &M : Modules)
> >module_list.Append(M);
> > ```
> >
> > Please look into making this change.
> Note that this is, of course, exactly why I've been saying all along that we
> should not even be discussing this here. Had the discussion happened over on
> the LLVM side the first time I asked about this, someone could have mentioned
> this without me having to spend time looking into it.
As long as those routines allow you to recursively call those routines, then
great, go for it.
The spinning up/tearing down of threads is not expensive, at least in my
measured use case.
Repository:
rL LLVM
https://reviews.llvm.org/D32597
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32823: Remove an expensive lock from Timer
scott.smith created this revision.
The Timer destructor would grab a global mutex in order to update execution
time. Add a class to define a category once, statically; the class adds itself
to an atomic singly linked list, and thus subsequent updates only need to use
an atomic rather than grab a lock and perform a hashtable lookup.
Repository:
rL LLVM
https://reviews.llvm.org/D32823
Files:
include/lldb/Core/Timer.h
source/API/SystemInitializerFull.cpp
source/Commands/CommandObjectTarget.cpp
source/Core/Disassembler.cpp
source/Core/Mangled.cpp
source/Core/Module.cpp
source/Core/Timer.cpp
source/Host/common/Symbols.cpp
source/Initialization/SystemInitializerCommon.cpp
source/Interpreter/CommandInterpreter.cpp
source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp
source/Plugins/SymbolFile/DWARF/DWARFDebugAranges.cpp
source/Plugins/SymbolFile/DWARF/DWARFDebugLine.cpp
source/Plugins/SymbolFile/DWARF/DWARFDebugPubnames.cpp
source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
source/Plugins/SymbolVendor/ELF/SymbolVendorELF.cpp
source/Symbol/DWARFCallFrameInfo.cpp
source/Symbol/ObjectFile.cpp
source/Symbol/Symtab.cpp
source/Target/Target.cpp
source/Target/TargetList.cpp
Index: source/Target/TargetList.cpp
===
--- source/Target/TargetList.cpp
+++ source/Target/TargetList.cpp
@@ -325,7 +325,8 @@
lldb::PlatformSP &platform_sp,
lldb::TargetSP &target_sp,
bool is_dummy_target) {
- Timer scoped_timer(LLVM_PRETTY_FUNCTION,
+ static TimerCategory func_cat(LLVM_PRETTY_FUNCTION);
+ Timer scoped_timer(func_cat,
"TargetList::CreateTarget (file = '%s', arch = '%s')",
user_exe_path.str().c_str(),
specified_arch.GetArchitectureName());
Index: source/Target/Target.cpp
===
--- source/Target/Target.cpp
+++ source/Target/Target.cpp
@@ -1235,7 +1235,8 @@
ClearModules(false);
if (executable_sp) {
-Timer scoped_timer(LLVM_PRETTY_FUNCTION,
+static TimerCategory func_cat(LLVM_PRETTY_FUNCTION);
+Timer scoped_timer(func_cat,
"Target::SetExecutableModule (executable = '%s')",
executable_sp->GetFileSpec().GetPath().c_str());
Index: source/Symbol/Symtab.cpp
===
--- source/Symbol/Symtab.cpp
+++ source/Symbol/Symtab.cpp
@@ -220,7 +220,8 @@
// Protected function, no need to lock mutex...
if (!m_name_indexes_computed) {
m_name_indexes_computed = true;
-Timer scoped_timer(LLVM_PRETTY_FUNCTION, "%s", LLVM_PRETTY_FUNCTION);
+static TimerCategory func_cat(LLVM_PRETTY_FUNCTION);
+Timer scoped_timer(func_cat, "%s", LLVM_PRETTY_FUNCTION);
// Create the name index vector to be able to quickly search by name
const size_t num_symbols = m_symbols.size();
#if 1
@@ -433,7 +434,8 @@
bool add_demangled, bool add_mangled,
NameToIndexMap &name_to_index_map) const {
if (add_demangled || add_mangled) {
-Timer scoped_timer(LLVM_PRETTY_FUNCTION, "%s", LLVM_PRETTY_FUNCTION);
+static TimerCategory func_cat(LLVM_PRETTY_FUNCTION);
+Timer scoped_timer(func_cat, "%s", LLVM_PRETTY_FUNCTION);
std::lock_guard guard(m_mutex);
// Create the name index vector to be able to quickly search by name
@@ -595,7 +597,8 @@
bool remove_duplicates) const {
std::lock_guard guard(m_mutex);
- Timer scoped_timer(LLVM_PRETTY_FUNCTION, LLVM_PRETTY_FUNCTION);
+ static TimerCategory func_cat(LLVM_PRETTY_FUNCTION);
+ Timer scoped_timer(func_cat, LLVM_PRETTY_FUNCTION);
// No need to sort if we have zero or one items...
if (indexes.size() <= 1)
return;
@@ -621,7 +624,8 @@
std::vector &indexes) {
std::lock_guard guard(m_mutex);
- Timer scoped_timer(LLVM_PRETTY_FUNCTION, "%s", LLVM_PRETTY_FUNCTION);
+ static TimerCategory func_cat(LLVM_PRETTY_FUNCTION);
+ Timer scoped_timer(func_cat, "%s", LLVM_PRETTY_FUNCTION);
if (symbol_name) {
if (!m_name_indexes_computed)
InitNameIndexes();
@@ -637,7 +641,8 @@
std::vector &indexes) {
std::lock_guard guard(m_mutex);
- Timer scoped_timer(LLVM_PRETTY_FUNCTION, "%s", LLVM_PRETTY_FUNC
[Lldb-commits] [PATCH] D32597: Initiate loading of shared libraries in parallel
zturner added inline comments.
Comment at:
source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp:530-560
+ struct loader {
+DYLDRendezvous::iterator I;
+ModuleSP m;
+std::shared_future f;
+ };
+ std::vector loaders(num_to_load);
+ llvm::ThreadPool load_pool(
zturner wrote:
> I'm still unclear why we're still going down this route of adding a very
> specialized instance of parallelism to this one place, that is probably going
> to be less efficient than having a global thread pool (as now you will have
> to spin up and destroy the entire thread pool every time you go to load
> shared libraries).
>
> So, rather than keep repeating the same thing over and over, I went and
> looked into this a little bit. It turns out LLD has a large library of
> parallel algorithms in `lld/Include/lld/Parallel.h`. There is almost nothing
> specific to LLD in any of these algorithms however, and they should probably
> be moved to llvm support. Upon doing so, you will be able to write this code
> as:
>
> ```
> std::vector Modules(m_rendevous.size());
> llvm::parallel_for_each(make_integer_range(0, m_rendevous.size()), [this,
> &Modules](int I)
> {
> auto &R = m_rendevous[I];
> Modules[I] = LoadModuleAtAddress(R.file_spec, R.link_addr, R.base_addr,
> true);
> });
> for (const auto &M : Modules)
>module_list.Append(M);
> ```
>
> Please look into making this change.
Note that this is, of course, exactly why I've been saying all along that we
should not even be discussing this here. Had the discussion happened over on
the LLVM side the first time I asked about this, someone could have mentioned
this without me having to spend time looking into it.
Repository:
rL LLVM
https://reviews.llvm.org/D32597
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32597: Initiate loading of shared libraries in parallel
zturner requested changes to this revision.
zturner added inline comments.
This revision now requires changes to proceed.
Comment at:
source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp:530-560
+ struct loader {
+DYLDRendezvous::iterator I;
+ModuleSP m;
+std::shared_future f;
+ };
+ std::vector loaders(num_to_load);
+ llvm::ThreadPool load_pool(
I'm still unclear why we're still going down this route of adding a very
specialized instance of parallelism to this one place, that is probably going
to be less efficient than having a global thread pool (as now you will have to
spin up and destroy the entire thread pool every time you go to load shared
libraries).
So, rather than keep repeating the same thing over and over, I went and looked
into this a little bit. It turns out LLD has a large library of parallel
algorithms in `lld/Include/lld/Parallel.h`. There is almost nothing specific
to LLD in any of these algorithms however, and they should probably be moved to
llvm support. Upon doing so, you will be able to write this code as:
```
std::vector Modules(m_rendevous.size());
llvm::parallel_for_each(make_integer_range(0, m_rendevous.size()), [this,
&Modules](int I)
{
auto &R = m_rendevous[I];
Modules[I] = LoadModuleAtAddress(R.file_spec, R.link_addr, R.base_addr,
true);
});
for (const auto &M : Modules)
module_list.Append(M);
```
Please look into making this change.
Repository:
rL LLVM
https://reviews.llvm.org/D32597
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32787: Fix build error: no viable conversion from returned value of type 'int' to function return type 'sigset_t' (aka '__sigset_t')
probinson added a comment. In https://reviews.llvm.org/D32787#745099, @labath wrote: > Could it be that you just have stale cmake cache? That could easily be true. Rerunning cmake didn't fix it; short of deleting the entire build directory, is there a way to refresh the cache? Repository: rL LLVM https://reviews.llvm.org/D32787 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32820: Parallelize demangling
scott.smith added a comment. This commit uses TaskMapOverInt from change https://reviews.llvm.org/D32757, which hasn't landed yet. Repository: rL LLVM https://reviews.llvm.org/D32820 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32820: Parallelize demangling
scott.smith created this revision.
Use TaskMapOverInt to demangle the symbols in parallel. Defer categorization
of C++ symbols until later, when it can be determined what contexts are
definitely classes, and what might not be.
Repository:
rL LLVM
https://reviews.llvm.org/D32820
Files:
include/lldb/Utility/ConstString.h
source/Symbol/Symtab.cpp
Index: source/Symbol/Symtab.cpp
===
--- source/Symbol/Symtab.cpp
+++ source/Symbol/Symtab.cpp
@@ -22,6 +22,7 @@
#include "lldb/Symbol/Symtab.h"
#include "lldb/Utility/RegularExpression.h"
#include "lldb/Utility/Stream.h"
+#include "lldb/Utility/TaskPool.h"
using namespace lldb;
using namespace lldb_private;
@@ -243,42 +244,44 @@
m_name_to_index.Reserve(actual_count);
#endif
-NameToIndexMap::Entry entry;
-
-// The "const char *" in "class_contexts" must come from a
-// ConstString::GetCString()
-std::set class_contexts;
-UniqueCStringMap mangled_name_to_index;
-std::vector symbol_contexts(num_symbols, nullptr);
+struct demangle_state {
+ ConstString name_to_index[5];
+ ConstString selector_to_index[1];
+ ConstString const_context;
+ ConstString cxx_basename;
+ bool is_definitely_class_context = false;
+};
+std::vector states(num_symbols);
-for (entry.value = 0; entry.value < num_symbols; ++entry.value) {
- const Symbol *symbol = &m_symbols[entry.value];
+auto symbol_fn = [&states, this](size_t value) {
+ const Symbol *symbol = &m_symbols[value];
// Don't let trampolines get into the lookup by name map
// If we ever need the trampoline symbols to be searchable by name
// we can remove this and then possibly add a new bool to any of the
// Symtab functions that lookup symbols by name to indicate if they
// want trampolines.
if (symbol->IsTrampoline())
-continue;
+return;
+ demangle_state &state = states[value];
const Mangled &mangled = symbol->GetMangled();
- entry.cstring = mangled.GetMangledName();
- if (entry.cstring) {
-m_name_to_index.Append(entry);
+ ConstString cstring = mangled.GetMangledName();
+ if (cstring) {
+state.name_to_index[0] = cstring;
if (symbol->ContainsLinkerAnnotations()) {
// If the symbol has linker annotations, also add the version without
// the annotations.
- entry.cstring = ConstString(m_objfile->StripLinkerSymbolAnnotations(
-entry.cstring.GetStringRef()));
- m_name_to_index.Append(entry);
+ cstring = ConstString(m_objfile->StripLinkerSymbolAnnotations(
+cstring.GetStringRef()));
+ state.name_to_index[1] = cstring;
}
const SymbolType symbol_type = symbol->GetType();
if (symbol_type == eSymbolTypeCode ||
symbol_type == eSymbolTypeResolver) {
- llvm::StringRef entry_ref(entry.cstring.GetStringRef());
+ llvm::StringRef entry_ref(cstring.GetStringRef());
if (entry_ref[0] == '_' && entry_ref[1] == 'Z' &&
(entry_ref[2] != 'T' && // avoid virtual table, VTT structure,
// typeinfo structure, and typeinfo
@@ -290,103 +293,92 @@
{
CPlusPlusLanguage::MethodName cxx_method(
mangled.GetDemangledName(lldb::eLanguageTypeC_plus_plus));
-entry.cstring = ConstString(cxx_method.GetBasename());
-if (entry.cstring) {
+cstring = ConstString(cxx_method.GetBasename());
+if (cstring) {
// ConstString objects permanently store the string in the pool so
// calling
// GetCString() on the value gets us a const char * that will
// never go away
- const char *const_context =
- ConstString(cxx_method.GetContext()).GetCString();
-
- if (!const_context || const_context[0] == 0) {
-// No context for this function so this has to be a basename
-m_basename_to_index.Append(entry);
-// If there is no context (no namespaces or class scopes that
-// come before the function name) then this also could be a
-// fullname.
-m_name_to_index.Append(entry);
- } else {
-entry_ref = entry.cstring.GetStringRef();
-if (entry_ref[0] == '~' ||
-!cxx_method.GetQualifiers().empty()) {
- // The first character of the demangled basename is '~' which
- // means we have a class destructor. We can use this information
- // to help us know what is a class and what isn't.
- if (class_contexts.find(const_context) == class_contexts.end())
-
[Lldb-commits] [PATCH] D32787: Fix build error: no viable conversion from returned value of type 'int' to function return type 'sigset_t' (aka '__sigset_t')
labath added a comment. In https://reviews.llvm.org/D32787#744974, @probinson wrote: > Looking at CMakeError.log, the test program does `#include ` but does > not `#define _GNU_SOURCE`. The define has to be there for your example to > compile on my Ubuntu. We do that in LLDBGenerateConfig.cmake:7. However, a previous version of the ppoll patch did not have the correct define. Could it be that you just have stale cmake cache? Repository: rL LLVM https://reviews.llvm.org/D32787 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32597: Initiate loading of shared libraries in parallel
scott.smith updated this revision to Diff 97695.
scott.smith added a comment.
update to use a private llvm::ThreadPool. I chose this over a 2nd global
"TaskPool" because if the threads are going to be short lived, there isn't much
point in having a global pool rather than a short-lived instantiated one.
Repository:
rL LLVM
https://reviews.llvm.org/D32597
Files:
source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp
source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.h
Index: source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.h
===
--- source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.h
+++ source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.h
@@ -66,6 +66,10 @@
uint32_t GetPluginVersion() override;
protected:
+ /// Mutex to protect various global variables during parallel shared library
+ /// loading.
+ std::recursive_mutex m_mutex;
+
/// Runtime linker rendezvous structure.
DYLDRendezvous m_rendezvous;
Index: source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp
===
--- source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp
+++ source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp
@@ -27,6 +27,7 @@
#include "lldb/Target/Thread.h"
#include "lldb/Target/ThreadPlanRunToAddress.h"
#include "lldb/Utility/Log.h"
+#include "llvm/Support/ThreadPool.h"
// C++ Includes
// C Includes
@@ -195,6 +196,7 @@
}
void DynamicLoaderPOSIXDYLD::DidLaunch() {
+ std::lock_guard guard(m_mutex);
Log *log(GetLogIfAnyCategoriesSet(LIBLLDB_LOG_DYNAMIC_LOADER));
if (log)
log->Printf("DynamicLoaderPOSIXDYLD::%s()", __FUNCTION__);
@@ -228,17 +230,20 @@
addr_t link_map_addr,
addr_t base_addr,
bool base_addr_is_offset) {
+ std::lock_guard guard(m_mutex);
m_loaded_modules[module] = link_map_addr;
UpdateLoadedSectionsCommon(module, base_addr, base_addr_is_offset);
}
void DynamicLoaderPOSIXDYLD::UnloadSections(const ModuleSP module) {
+ std::lock_guard guard(m_mutex);
m_loaded_modules.erase(module);
UnloadSectionsCommon(module);
}
void DynamicLoaderPOSIXDYLD::ProbeEntry() {
+ std::lock_guard guard(m_mutex);
Log *log(GetLogIfAnyCategoriesSet(LIBLLDB_LOG_DYNAMIC_LOADER));
const addr_t entry = GetEntryPoint();
@@ -329,6 +334,7 @@
}
void DynamicLoaderPOSIXDYLD::SetRendezvousBreakpoint() {
+ std::lock_guard guard(m_mutex);
Log *log(GetLogIfAnyCategoriesSet(LIBLLDB_LOG_DYNAMIC_LOADER));
addr_t break_addr = m_rendezvous.GetBreakAddress();
@@ -372,6 +378,7 @@
Log *log(GetLogIfAnyCategoriesSet(LIBLLDB_LOG_DYNAMIC_LOADER));
DynamicLoaderPOSIXDYLD *const dyld_instance =
static_cast(baton);
+ std::lock_guard guard(dyld_instance->m_mutex);
if (log)
log->Printf("DynamicLoaderPOSIXDYLD::%s called for pid %" PRIu64,
__FUNCTION__,
@@ -393,6 +400,7 @@
}
void DynamicLoaderPOSIXDYLD::RefreshModules() {
+ std::lock_guard guard(m_mutex);
if (!m_rendezvous.Resolve())
return;
@@ -437,6 +445,7 @@
ThreadPlanSP
DynamicLoaderPOSIXDYLD::GetStepThroughTrampolinePlan(Thread &thread,
bool stop) {
+ std::lock_guard guard(m_mutex);
ThreadPlanSP thread_plan_sp;
StackFrame *frame = thread.GetStackFrameAtIndex(0).get();
@@ -514,14 +523,33 @@
std::vector module_names;
for (I = m_rendezvous.begin(), E = m_rendezvous.end(); I != E; ++I)
module_names.push_back(I->file_spec);
+ size_t num_to_load = module_names.size();
m_process->PrefetchModuleSpecs(
module_names, m_process->GetTarget().GetArchitecture().GetTriple());
- for (I = m_rendezvous.begin(), E = m_rendezvous.end(); I != E; ++I) {
-ModuleSP module_sp =
-LoadModuleAtAddress(I->file_spec, I->link_addr, I->base_addr, true);
-if (module_sp.get()) {
- module_list.Append(module_sp);
+ struct loader {
+DYLDRendezvous::iterator I;
+ModuleSP m;
+std::shared_future f;
+ };
+ std::vector loaders(num_to_load);
+ llvm::ThreadPool load_pool(
+std::min(num_to_load, std::thread::hardware_concurrency()));
+ auto loader_fn = [this](loader * l)
+ {
+l->m = LoadModuleAtAddress(
+ l->I->file_spec, l->I->link_addr, l->I->base_addr, true);
+ };
+
+ loader * l = loaders.data();
+ for (I = m_rendezvous.begin(), E = m_rendezvous.end(); I != E; ++I, ++l) {
+l->I = I;
+l->f = load_pool.async(loader_fn, l);
+ }
+ for (auto & l : loaders) {
+l.f.wait();
+if (l.m.get()) {
+ module_list.Append(l.m);
} else {
Log *log(GetLogIfAnyCategoriesSet(LIBLLDB_LOG_DYNAMIC_LOADER));
if (log)
@@ -535,6 +563,7 @@
}
addr_t DynamicLoaderPOSIXDYLD::ComputeLoadOff
[Lldb-commits] [PATCH] D30007: [lldb] Provide API to know which sanitizer generated an eStopReasonInstrumentation
jingham accepted this revision. jingham added a comment. This revision is now accepted and ready to land. Sorry for the delay. That's fine. https://reviews.llvm.org/D30007 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32732: "target variable" not showing all global variable if we print any global variable before execution starts
jingham added a reviewer: jingham. jingham requested changes to this revision. jingham added a comment. This revision now requires changes to proceed. I actually think the behavior you are seeing is the designed behavior, but it isn't clearly documented. Target variable is designed to help manage the large number of global & static variables that you can have in a complex system. So we avoid having the command with no arguments just dumping all the global variables in every library in the program in most cases. That can be pages and pages of output... The current method for this is: before you run, when target variable has no context, it will either search for globals & statics by name if you provide them, or show all the globals in whatever shared libraries you name. It doesn't ever show all globals everywhere in this case: > lldb ~/Projects/Sketch/build/Debug/Sketch.app (lldb) target create "/Volumes/ThePlayground/Users/jingham/Projects/Sketch/build/Debug/Sketch.app" Current executable set to '/Volumes/ThePlayground/Users/jingham/Projects/Sketch/build/Debug/Sketch.app' (x86_64). (lldb) target variable error: 'target variable' takes one or more global variable names as arguments (lldb) target variable SKTAppAutosavingDelayPreferenceKey (NSString *) SKTAppAutosavingDelayPreferenceKey = 0x0001000223f8 (lldb) target variable --shlib Sketch Global variables for /Volumes/ThePlayground/Users/jingham/Projects/Sketch/build/Debug/Sketch.app/Contents/MacOS/Sketch (NSString *) SKTAppAutosavingDelayPreferenceKey = 0x0001000223f8 (NSString *) SKTAppAutosavesPreferenceKey = 0x0001000223d8 ... That first error could be a little nicer, actually... Then when you are in a frame scope, what we show by default is the statics and globals defined in the CU holding that frame. That is why you aren't seeing other variables once you've stopped. If you want to broaden the search you can either specify a name, or specify a shared library. I think the current behavior is preferable to dumping all the globals, which if you have debug information for a substantial part of the system is overwhelming and not useful. I'm also confused about the changes to the expression parser lookup. The expression parser isn't trying to limit information in the way "target variable" does, and should already look everywhere for globals (of course starting from the current frame -> containing CU -> containing dylib and finally out to all dylibs. I don't see any indication from your examples that this isn't working, and your test only test "target variable", it doesn't use the expression parser. Repository: rL LLVM https://reviews.llvm.org/D32732 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D30007: [lldb] Provide API to know which sanitizer generated an eStopReasonInstrumentation
clayborg accepted this revision. clayborg added a comment. Looks fine to me, make sure Jim is happy as well. https://reviews.llvm.org/D30007 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32787: Fix build error: no viable conversion from returned value of type 'int' to function return type 'sigset_t' (aka '__sigset_t')
probinson added a comment. Looking at CMakeError.log, the test program does `#include ` but does not `#define _GNU_SOURCE`. The define has to be there for your example to compile on my Ubuntu. Repository: rL LLVM https://reviews.llvm.org/D32787 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32813: ABISysV_arm64: compute return value for large vectors correctly
labath created this revision.
Herald added subscribers: srhines, rengolin, aemerson.
Arm64 Procedure Call Standard specifies than only vectors up to 16 bytes
are stored in v0 (which makes sense, as that's the size of the
register). 32-byte vector types are passed as regular structs via x8
pointer. Treat them as such.
This fixes TestReturnValue for arm64-clang. I also split the test case
into two so I can avoid the if(gcc) line, and annotate each test
instead. (It seems the vector type tests fail with gcc only when
targetting x86 arches).
https://reviews.llvm.org/D32813
Files:
packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py
source/Plugins/ABI/SysV-arm64/ABISysV_arm64.cpp
Index: source/Plugins/ABI/SysV-arm64/ABISysV_arm64.cpp
===
--- source/Plugins/ABI/SysV-arm64/ABISysV_arm64.cpp
+++ source/Plugins/ABI/SysV-arm64/ABISysV_arm64.cpp
@@ -2362,32 +2362,30 @@
if (success)
return_valobj_sp = ValueObjectConstResult::Create(
thread.GetStackFrameAtIndex(0).get(), value, ConstString(""));
- } else if (type_flags & eTypeIsVector) {
+ } else if (type_flags & eTypeIsVector && byte_size <= 16) {
if (byte_size > 0) {
const RegisterInfo *v0_info = reg_ctx->GetRegisterInfoByName("v0", 0);
if (v0_info) {
-if (byte_size <= v0_info->byte_size) {
- std::unique_ptr heap_data_ap(
- new DataBufferHeap(byte_size, 0));
- const ByteOrder byte_order = exe_ctx.GetProcessRef().GetByteOrder();
- RegisterValue reg_value;
- if (reg_ctx->ReadRegister(v0_info, reg_value)) {
-Error error;
-if (reg_value.GetAsMemoryData(v0_info, heap_data_ap->GetBytes(),
- heap_data_ap->GetByteSize(),
- byte_order, error)) {
- DataExtractor data(DataBufferSP(heap_data_ap.release()),
- byte_order,
- exe_ctx.GetProcessRef().GetAddressByteSize());
- return_valobj_sp = ValueObjectConstResult::Create(
- &thread, return_compiler_type, ConstString(""), data);
-}
+std::unique_ptr heap_data_ap(
+new DataBufferHeap(byte_size, 0));
+const ByteOrder byte_order = exe_ctx.GetProcessRef().GetByteOrder();
+RegisterValue reg_value;
+if (reg_ctx->ReadRegister(v0_info, reg_value)) {
+ Error error;
+ if (reg_value.GetAsMemoryData(v0_info, heap_data_ap->GetBytes(),
+heap_data_ap->GetByteSize(), byte_order,
+error)) {
+DataExtractor data(DataBufferSP(heap_data_ap.release()), byte_order,
+ exe_ctx.GetProcessRef().GetAddressByteSize());
+return_valobj_sp = ValueObjectConstResult::Create(
+&thread, return_compiler_type, ConstString(""), data);
}
}
}
}
- } else if (type_flags & eTypeIsStructUnion || type_flags & eTypeIsClass) {
+ } else if (type_flags & eTypeIsStructUnion || type_flags & eTypeIsClass ||
+ (type_flags & eTypeIsVector && byte_size > 16)) {
DataExtractor data;
uint32_t NGRN = 0; // Search ABI docs for NGRN
Index: packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py
===
--- packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py
+++ packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py
@@ -171,17 +171,45 @@
#self.return_and_test_struct_value ("return_one_int_one_double_packed")
self.return_and_test_struct_value("return_one_int_one_long")
-# icc and gcc don't support this extension.
-if self.getCompiler().endswith('clang'):
-self.return_and_test_struct_value("return_vector_size_float32_8")
-self.return_and_test_struct_value("return_vector_size_float32_16")
-self.return_and_test_struct_value("return_vector_size_float32_32")
-self.return_and_test_struct_value(
-"return_ext_vector_size_float32_2")
-self.return_and_test_struct_value(
-"return_ext_vector_size_float32_4")
-self.return_and_test_struct_value(
-"return_ext_vector_size_float32_8")
+@expectedFailureAll(oslist=["freebsd"], archs=["i386"])
+@expectedFailureAll(oslist=["macosx"], archs=["i386"], bugnumber="")
+@expectedFailureAll(
+oslist=["linux"],
+compiler="clang",
+compiler_version=[
+"<=",
+"3.6"],
+archs=["i386"])
+@expectedFailureAll(
+bugnumber="llvm.org/pr25785",
+hostoslist=["windows"],
+compiler="gcc",
+archs=["i386"],
+tr
[Lldb-commits] [PATCH] D30007: [lldb] Provide API to know which sanitizer generated an eStopReasonInstrumentation
kubamracek added a comment. This revision now requires changes to proceed. ping https://reviews.llvm.org/D30007 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32719: Don't attempt to use mpx registers on unsupported platforms
This revision was automatically updated to reflect the committed changes.
Closed by commit rL302027: Don't attempt to use mpx registers on unsupported
platforms (authored by fjricci).
Changed prior to commit:
https://reviews.llvm.org/D32719?vs=97447&id=97648#toc
Repository:
rL LLVM
https://reviews.llvm.org/D32719
Files:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/main.cpp
lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/mpx_bound_violation/main.cpp
Index:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/main.cpp
===
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/main.cpp
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/main.cpp
@@ -14,6 +14,11 @@
int
main(int argc, char const *argv[])
{
+// PR_MPX_ENABLE_MANAGEMENT won't be defined on linux kernel versions below
3.19
+#ifndef PR_MPX_ENABLE_MANAGEMENT
+return -1;
+#endif
+
// This call returns 0 only if the CPU and the kernel support Intel(R) MPX.
if (prctl(PR_MPX_ENABLE_MANAGEMENT, 0, 0, 0, 0) != 0)
return -1;
Index:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/mpx_bound_violation/main.cpp
===
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/mpx_bound_violation/main.cpp
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/mpx_bound_violation/main.cpp
@@ -29,6 +29,11 @@
unsigned int rax, rbx, rcx, rdx;
int array[5];
+// PR_MPX_ENABLE_MANAGEMENT won't be defined on linux kernel versions below
3.19
+#ifndef PR_MPX_ENABLE_MANAGEMENT
+return -1;
+#endif
+
// This call returns 0 only if the CPU and the kernel support Intel(R) MPX.
if (prctl(PR_MPX_ENABLE_MANAGEMENT, 0, 0, 0, 0) != 0)
return -1;
Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/main.cpp
===
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/main.cpp
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/main.cpp
@@ -14,6 +14,11 @@
int
main(int argc, char const *argv[])
{
+// PR_MPX_ENABLE_MANAGEMENT won't be defined on linux kernel versions below 3.19
+#ifndef PR_MPX_ENABLE_MANAGEMENT
+return -1;
+#endif
+
// This call returns 0 only if the CPU and the kernel support Intel(R) MPX.
if (prctl(PR_MPX_ENABLE_MANAGEMENT, 0, 0, 0, 0) != 0)
return -1;
Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/mpx_bound_violation/main.cpp
===
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/mpx_bound_violation/main.cpp
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/mpx_bound_violation/main.cpp
@@ -29,6 +29,11 @@
unsigned int rax, rbx, rcx, rdx;
int array[5];
+// PR_MPX_ENABLE_MANAGEMENT won't be defined on linux kernel versions below 3.19
+#ifndef PR_MPX_ENABLE_MANAGEMENT
+return -1;
+#endif
+
// This call returns 0 only if the CPU and the kernel support Intel(R) MPX.
if (prctl(PR_MPX_ENABLE_MANAGEMENT, 0, 0, 0, 0) != 0)
return -1;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r302027 - Don't attempt to use mpx registers on unsupported platforms
Author: fjricci
Date: Wed May 3 10:00:04 2017
New Revision: 302027
URL: http://llvm.org/viewvc/llvm-project?rev=302027&view=rev
Log:
Don't attempt to use mpx registers on unsupported platforms
Summary:
The existing cpp-level checks using PR_MPX_ENABLE_MANAGEMENT aren't sufficient,
as this isn't defined for linux kernel versions below 3.19.
Reviewers: valentinagiusti, zturner, labath
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D32719
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/main.cpp
lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/mpx_bound_violation/main.cpp
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/main.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/main.cpp?rev=302027&r1=302026&r2=302027&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/main.cpp
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/main.cpp
Wed May 3 10:00:04 2017
@@ -14,6 +14,11 @@
int
main(int argc, char const *argv[])
{
+// PR_MPX_ENABLE_MANAGEMENT won't be defined on linux kernel versions below
3.19
+#ifndef PR_MPX_ENABLE_MANAGEMENT
+return -1;
+#endif
+
// This call returns 0 only if the CPU and the kernel support Intel(R) MPX.
if (prctl(PR_MPX_ENABLE_MANAGEMENT, 0, 0, 0, 0) != 0)
return -1;
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/mpx_bound_violation/main.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/mpx_bound_violation/main.cpp?rev=302027&r1=302026&r2=302027&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/mpx_bound_violation/main.cpp
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/mpx_bound_violation/main.cpp
Wed May 3 10:00:04 2017
@@ -29,6 +29,11 @@ main(int argc, char const *argv[])
unsigned int rax, rbx, rcx, rdx;
int array[5];
+// PR_MPX_ENABLE_MANAGEMENT won't be defined on linux kernel versions below
3.19
+#ifndef PR_MPX_ENABLE_MANAGEMENT
+return -1;
+#endif
+
// This call returns 0 only if the CPU and the kernel support Intel(R) MPX.
if (prctl(PR_MPX_ENABLE_MANAGEMENT, 0, 0, 0, 0) != 0)
return -1;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32757: Add TaskMap for iterating a function over a set of integers
clayborg accepted this revision. clayborg added a comment. -glldb doesn't emit the Apple accelerator tables IIRC. We don't need to change the DWARF, but just add the Apple accelerator tables by modifying clang to emit them. They will be just fine with DWO as each DWO file would have a set of them. The other way to do this to just check out if this works is to modify "llvm-dsymutil --update" to be able to work on ELF files. "llvm-dsymutil --update" regenerates the accelerator tables and puts them into the DWARF using an existing file with debug info. It was made in case we missing something in the accelerator tables that we added later so we could update old DWARF files gotten from build servers. That being said, if no one is going to miss TaskRunner then we can let it go. Repository: rL LLVM https://reviews.llvm.org/D32757 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r302013 - Windows fix for TestConflictingDefinition makefile
Author: labath Date: Wed May 3 06:27:35 2017 New Revision: 302013 URL: http://llvm.org/viewvc/llvm-project?rev=302013&view=rev Log: Windows fix for TestConflictingDefinition makefile gnuwin32 rm does not like wildcards that match nothing even if we specify -f (probably because the wildcard expansion happens in-process there). We could use make $(wildcard) here, but it seems safer to explicitly list the files here, just like the normal Makefile.rules does. Modified: lldb/trunk/packages/Python/lldbsuite/test/lang/objc/conflicting-definition/Makefile Modified: lldb/trunk/packages/Python/lldbsuite/test/lang/objc/conflicting-definition/Makefile URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/objc/conflicting-definition/Makefile?rev=302013&r1=302012&r2=302013&view=diff == --- lldb/trunk/packages/Python/lldbsuite/test/lang/objc/conflicting-definition/Makefile (original) +++ lldb/trunk/packages/Python/lldbsuite/test/lang/objc/conflicting-definition/Makefile Wed May 3 06:27:35 2017 @@ -21,4 +21,4 @@ a.out: main.m libTest.dylib libTestExt.d .PHONY: clean clean: - rm -rf *.dylib a.out *.o *.dSYM *.d + rm -rf libTest.dylib libTestExt.dylib a.out Test.o TestExt.o libTest.dylib.dSYM libTest.dylib.dSYM ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32757: Add TaskMap for iterating a function over a set of integers
tberghammer added a comment. Personally I never really liked TaskRunner (even though I was the one implemented it) because I think it adds a lot of extra complexity for fairly little gain and thinking about it a bit more I think in most use case a more targeted solution at the call site will probably give better results. Also if we need it in the future it can always be restored based on git/svn history. Based on that I am happy to delete it if we have no use case for it at the moment. Regarding Apple accelerator tables, giving it a try can be interesting (pass '-glldb' to a sufficiently new clang) but as far as I know they are not compatible with split dwarf what can be show stopper for very large applications (e.g. linking chromium on linux with "no-limit-debug-info" and without split dwarf requires unreasonably large amount of memory). Repository: rL LLVM https://reviews.llvm.org/D32757 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r302008 - Check for lack of C++ context first when demangling
Author: labath
Date: Wed May 3 05:00:00 2017
New Revision: 302008
URL: http://llvm.org/viewvc/llvm-project?rev=302008&view=rev
Log:
Check for lack of C++ context first when demangling
Summary: It seems that if we have no context, then it can't possibly be a
method. Check that first.
Reviewers: clayborg
Reviewed By: clayborg
Subscribers: labath, lldb-commits
Differential Revision: https://reviews.llvm.org/D32708
Patch by Scott Smith .
Modified:
lldb/trunk/source/Symbol/Symtab.cpp
Modified: lldb/trunk/source/Symbol/Symtab.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Symbol/Symtab.cpp?rev=302008&r1=302007&r2=302008&view=diff
==
--- lldb/trunk/source/Symbol/Symtab.cpp (original)
+++ lldb/trunk/source/Symbol/Symtab.cpp Wed May 3 05:00:00 2017
@@ -299,17 +299,24 @@ void Symtab::InitNameIndexes() {
const char *const_context =
ConstString(cxx_method.GetContext()).GetCString();
- entry_ref = entry.cstring.GetStringRef();
- if (entry_ref[0] == '~' ||
- !cxx_method.GetQualifiers().empty()) {
-// The first character of the demangled basename is '~' which
-// means we have a class destructor. We can use this
information
-// to help us know what is a class and what isn't.
-if (class_contexts.find(const_context) == class_contexts.end())
- class_contexts.insert(const_context);
-m_method_to_index.Append(entry);
+ if (!const_context || const_context[0] == 0) {
+// No context for this function so this has to be a basename
+m_basename_to_index.Append(entry);
+// If there is no context (no namespaces or class scopes that
+// come before the function name) then this also could be a
+// fullname.
+m_name_to_index.Append(entry);
} else {
-if (const_context && const_context[0]) {
+entry_ref = entry.cstring.GetStringRef();
+if (entry_ref[0] == '~' ||
+!cxx_method.GetQualifiers().empty()) {
+ // The first character of the demangled basename is '~' which
+ // means we have a class destructor. We can use this
information
+ // to help us know what is a class and what isn't.
+ if (class_contexts.find(const_context) ==
class_contexts.end())
+class_contexts.insert(const_context);
+ m_method_to_index.Append(entry);
+} else {
if (class_contexts.find(const_context) !=
class_contexts.end()) {
// The current decl context is in our "class_contexts"
which
@@ -326,14 +333,6 @@ void Symtab::InitNameIndexes() {
mangled_name_to_index.Append(entry);
symbol_contexts[entry.value] = const_context;
}
-} else {
- // No context for this function so this has to be a basename
- m_basename_to_index.Append(entry);
- // If there is no context (no namespaces or class scopes that
- // come before the function name) then this also could be a
- // fullname.
- if (cxx_method.GetContext().empty())
-m_name_to_index.Append(entry);
}
}
}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32787: Fix build error: no viable conversion from returned value of type 'int' to function return type 'sigset_t' (aka '__sigset_t')
labath added a comment. In https://reviews.llvm.org/D32787#744379, @xiangzhai wrote: > Hi Pavel, > > > Could one of you guys check whether you really don't have the ppoll syscall > > (for example, are able to compile a simple program using ppoll (*)) > > It has! clang is able to compile the simple program! > > > If you do, then I may need a bit more help to debug the cmake detection > > logic > > Yes, it needs to add the detection logic in the CMakeLists.txt :) We already have it, it's in lldb/cmake/modules/LLDBGenerateConfig.cmake. We need to figure out why it's not working. If you have some experience with cmake, it would be easiest if you could investigate yourself. Otherwise we'll have to do some remote debugging. If you can send me your CMakeError.log and CMakeOutput.log, I may be able to figure out what's going on. Repository: rL LLVM https://reviews.llvm.org/D32787 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32787: Fix build error: no viable conversion from returned value of type 'int' to function return type 'sigset_t' (aka '__sigset_t')
xiangzhai added a comment. Hi Pavel, > Could one of you guys check whether you really don't have the ppoll syscall > (for example, are able to compile a simple program using ppoll (*)) It has! clang is able to compile the simple program! > If you do, then I may need a bit more help to debug the cmake detection logic Yes, it needs to add the detection logic in the CMakeLists.txt :) Regards, Leslie Zhai Repository: rL LLVM https://reviews.llvm.org/D32787 ___ 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
vbalu updated this revision to Diff 97575.
vbalu marked an inline comment as done.
vbalu added a comment.
modified exe path computation
Repository:
rL LLVM
https://reviews.llvm.org/D32522
Files:
packages/Python/lldbsuite/test/functionalities/process_attach/TestProcessAttach.py
Index:
packages/Python/lldbsuite/test/functionalities/process_attach/TestProcessAttach.py
===
---
packages/Python/lldbsuite/test/functionalities/process_attach/TestProcessAttach.py
+++
packages/Python/lldbsuite/test/functionalities/process_attach/TestProcessAttach.py
@@ -8,6 +8,7 @@
import os
import time
import lldb
+import shutil
from lldbsuite.test.decorators import *
from lldbsuite.test.lldbtest import *
from lldbsuite.test import lldbutil
@@ -38,6 +39,25 @@
process = target.GetProcess()
self.assertTrue(process, PROCESS_IS_VALID)
+def test_attach_to_process_frm_different_dir_by_id(self):
+"""Test attach by process id"""
+os.mkdir(os.path.join(os.getcwd(),'newdir'))
+self.buildProgram('main.cpp','newdir/proc_attach')
+exe = os.path.join('.','newdir','proc_attach')
+self.addTearDownHook(lambda: shutil.rmtree(os.path.join(os.getcwd(
+
+# Spawn a new process
+popen = self.spawnSubprocess(exe)
+self.addTearDownHook(self.cleanupSubprocesses)
+
+os.chdir('newdir')
+self.runCmd("process attach -p " + str(popen.pid))
+
+target = self.dbg.GetSelectedTarget()
+
+process = target.GetProcess()
+self.assertTrue(process, PROCESS_IS_VALID)
+
def test_attach_to_process_by_name(self):
"""Test attach by process name"""
self.build()
Index: packages/Python/lldbsuite/test/functionalities/process_attach/TestProcessAttach.py
===
--- packages/Python/lldbsuite/test/functionalities/process_attach/TestProcessAttach.py
+++ packages/Python/lldbsuite/test/functionalities/process_attach/TestProcessAttach.py
@@ -8,6 +8,7 @@
import os
import time
import lldb
+import shutil
from lldbsuite.test.decorators import *
from lldbsuite.test.lldbtest import *
from lldbsuite.test import lldbutil
@@ -38,6 +39,25 @@
process = target.GetProcess()
self.assertTrue(process, PROCESS_IS_VALID)
+def test_attach_to_process_frm_different_dir_by_id(self):
+"""Test attach by process id"""
+os.mkdir(os.path.join(os.getcwd(),'newdir'))
+self.buildProgram('main.cpp','newdir/proc_attach')
+exe = os.path.join('.','newdir','proc_attach')
+self.addTearDownHook(lambda: shutil.rmtree(os.path.join(os.getcwd(
+
+# Spawn a new process
+popen = self.spawnSubprocess(exe)
+self.addTearDownHook(self.cleanupSubprocesses)
+
+os.chdir('newdir')
+self.runCmd("process attach -p " + str(popen.pid))
+
+target = self.dbg.GetSelectedTarget()
+
+process = target.GetProcess()
+self.assertTrue(process, PROCESS_IS_VALID)
+
def test_attach_to_process_by_name(self):
"""Test attach by process name"""
self.build()
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32787: Fix build error: no viable conversion from returned value of type 'int' to function return type 'sigset_t' (aka '__sigset_t')
labath requested changes to this revision.
labath added a subscriber: probinson.
labath added a comment.
This revision now requires changes to proceed.
This will not compile on windows, which really is the only branch we expected
to have `SIGNAL_POLLING_UNSUPPORTED` set. In this sense Pauls (cc'ed) fix is
better, but it does not actually get lldb going on the affected systems. Could
one of you guys check whether you really don't have the ppoll syscall (for
example, are able to compile a simple program using ppoll (*)). If you really
don't have ppoll, then I can hook up cmake so it falls back to pselect. If you
do, then I may need a bit more help to debug the cmake detection logic.
thank a lot.
(*) this will do the trick:
#define _GNU_SOURCE
#include
int main() { return ppoll(0, 0, 0, 0); }
Repository:
rL LLVM
https://reviews.llvm.org/D32787
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] Fix Ubuntu build break with gcc 5.4
It seems xiangzhai has already "cranked up a review" :) (D32787), so
moving the discussion there.
On 3 May 2017 at 09:57, Pavel Labath wrote:
> This doesn't make things any worse, but a better solution would be to
> figure out why cmake has not detected ppoll(2) support, as lldb on
> linux is useless without the signal polling stuff. If your system does
> have ppoll, but we're not detecting it, we will have to fix detection
> code. On the off chance that you don't have one (it was introduced
> ages ago, so I would be surprised by that, but I guess it's still
> possible), then we can fall back to using pselect(2).
>
>
>
> On 3 May 2017 at 00:13, Robinson, Paul via lldb-commits
> wrote:
>> Recently I started seeing a build error from a tree that has lldb in it;
>> I don't know whether the problem is my configuration, or Ubuntu, or gcc,
>> or what, but gcc complains that it can't convert 'int' to 'sigset_t' on
>> the return statement.
>>
>> This naïve one-liner fixes it, although I don't know anything about
>> signal stuff. Didn't seem worth cranking up a Phab review for this...
>> --paulr
>>
>> Index: source/Host/common/MainLoop.cpp
>> ===
>> --- source/Host/common/MainLoop.cpp (revision 301939)
>> +++ source/Host/common/MainLoop.cpp (working copy)
>> @@ -155,7 +155,7 @@
>>
>> sigset_t MainLoop::RunImpl::get_sigmask() {
>> #if SIGNAL_POLLING_UNSUPPORTED
>> - return 0;
>> + return sigset_t();
>> #else
>>sigset_t sigmask;
>>int ret = pthread_sigmask(SIG_SETMASK, nullptr, &sigmask);
>>
>>
>> ___
>> 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] D32421: Fix segfault resulting from empty print prompt
labath added a comment. It's definitely still a bug worth fixing, we cannot rely on undefined behavior like that. Thank you very much for adding the test case. Looking at the test suite again, I think I've found a better place for the test. Could you put the test in test/testcases/expression_command/multiline/TestMultilineExpressions.py. You don't even have to create a new file, just add a new function (`test_empty_list` ?) to the existing class. Other than that, I think this is great. https://reviews.llvm.org/D32421 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D32522: Test case for the issue raised in D32271
On 3 May 2017 at 07:41, vignesh balu wrote:
> you mean like this "exe = os.path.join('./newdir/','proc_attach')". I can't
probably something like: os.path.join('.', 'newdir', 'proc_attach')
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] Fix Ubuntu build break with gcc 5.4
This doesn't make things any worse, but a better solution would be to
figure out why cmake has not detected ppoll(2) support, as lldb on
linux is useless without the signal polling stuff. If your system does
have ppoll, but we're not detecting it, we will have to fix detection
code. On the off chance that you don't have one (it was introduced
ages ago, so I would be surprised by that, but I guess it's still
possible), then we can fall back to using pselect(2).
On 3 May 2017 at 00:13, Robinson, Paul via lldb-commits
wrote:
> Recently I started seeing a build error from a tree that has lldb in it;
> I don't know whether the problem is my configuration, or Ubuntu, or gcc,
> or what, but gcc complains that it can't convert 'int' to 'sigset_t' on
> the return statement.
>
> This naïve one-liner fixes it, although I don't know anything about
> signal stuff. Didn't seem worth cranking up a Phab review for this...
> --paulr
>
> Index: source/Host/common/MainLoop.cpp
> ===
> --- source/Host/common/MainLoop.cpp (revision 301939)
> +++ source/Host/common/MainLoop.cpp (working copy)
> @@ -155,7 +155,7 @@
>
> sigset_t MainLoop::RunImpl::get_sigmask() {
> #if SIGNAL_POLLING_UNSUPPORTED
> - return 0;
> + return sigset_t();
> #else
>sigset_t sigmask;
>int ret = pthread_sigmask(SIG_SETMASK, nullptr, &sigmask);
>
>
> ___
> 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] D32732: "target variable" not showing all global variable if we print any global variable before execution starts
vbalu updated this revision to Diff 97569.
vbalu added a comment.
Herald added a subscriber: srhines.
Added the test case.
Repository:
rL LLVM
https://reviews.llvm.org/D32732
Files:
packages/Python/lldbsuite/test/functionalities/target_command/TestTargetCommand.py
packages/Python/lldbsuite/test/functionalities/target_command/globals.c
source/Commands/CommandObjectTarget.cpp
source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.h
Index: source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.h
===
--- source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.h
+++ source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.h
@@ -303,6 +303,23 @@
TargetInfo GetTargetInfo();
//--
+ /// Used to parse all the variable declared in globa score before accssing
+ /// indivually when user try to see the global symbol before starting
+ /// execution.
+ ///
+ /// @param[in] target
+ /// The target to find the symbol in.
+ ///
+ /// @param[in] name
+ /// Symbol name that user try to print.
+ ///
+ /// @return
+ /// True on success; false otherwise.
+ //--
+
+ void ParseGlobalVariablesInScopeZero(Target &target, const ConstString name);
+
+ //--
/// [Used by ClangASTSource] Find all entities matching a given name,
/// using a NameSearchContext to make Decls for them.
///
Index: source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
===
--- source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
+++ source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
@@ -733,6 +733,28 @@
frame_decl_context.GetTypeSystem());
}
+void ClangExpressionDeclMap::ParseGlobalVariablesInScopeZero(
+Target &target, const ConstString name) {
+ const Symbol *symbol = FindGlobalDataSymbol(target, name, NULL);
+ ModuleSP module;
+
+ if (!symbol)
+return;
+
+ if (symbol->ValueIsAddress())
+module = symbol->GetAddressRef().GetModule();
+
+ SymbolVendor *vendor_sym = module->GetSymbolVendor(true, NULL);
+ SymbolContext sc;
+
+ sc.module_sp = module;
+ sc.comp_unit = symbol->GetAddress().CalculateSymbolContextCompileUnit();
+
+ vendor_sym->ParseVariablesForContext(sc);
+
+ return;
+}
+
// Interface for ClangASTSource
void ClangExpressionDeclMap::FindExternalVisibleDecls(
@@ -1229,6 +1251,11 @@
}
}
if (target) {
+ // Looks like trying to find a variable before program is run.
+ // So parse the global variable for declaration.
+
+ ParseGlobalVariablesInScopeZero(*target, name);
+
var = FindGlobalVariable(*target, module_sp, name, &namespace_decl, NULL);
if (var) {
Index: source/Commands/CommandObjectTarget.cpp
===
--- source/Commands/CommandObjectTarget.cpp
+++ source/Commands/CommandObjectTarget.cpp
@@ -836,9 +836,25 @@
return false;
}
use_var_name = true;
+ if (!m_exe_ctx.GetFramePtr()) {
+VariableList list;
+lldb_private::RegularExpression all_globals_regex(".");
+target->GetImages().FindGlobalVariables(all_globals_regex, true,
+UINT32_MAX, list);
+ }
matches = target->GetImages().FindGlobalVariables(
regex, true, UINT32_MAX, variable_list);
} else {
+ // if there is no frame then it is before "r" ing the exe, so just
+ // parse all the variables
+ // before picking proper otherwise we end up adding only this variable
+ // in m_variables
+ if (!m_exe_ctx.GetFramePtr()) {
+VariableList list;
+lldb_private::RegularExpression all_globals_regex(".");
+target->GetImages().FindGlobalVariables(all_globals_regex, true,
+UINT32_MAX, list);
+ }
Error error(Variable::GetValuesForVariableExpressionPath(
arg, m_exe_ctx.GetBestExecutionContextScope(),
GetVariableCallback, target, variable_list, valobj_list));
Index: packages/Python/lldbsuite/test/functionalities/target_command/globals.c
===
--- packages/Python/lldbsuite/test/functionalities/target_command/globals.c
+++ packages/Python/lldbsuite/test/functionalities/target_command/globals.c
@@ -12,6 +12,7 @@
const char* my_global_str = "abc";
const char **my_global_str_ptr = &my_global_str;
static int my_static_int = 228;
+int my_global_int = 10;
int main (int argc,
[Lldb-commits] [PATCH] D32787: Fix build error: no viable conversion from returned value of type 'int' to function return type 'sigset_t' (aka '__sigset_t')
xiangzhai created this revision.
Hi LLVM developers,
Resurrect pselect MainLoop implementation https://reviews.llvm.org/D32600
commited by Pavel, then it failed to build for Linux:
/data/project/LLVM/llvm/tools/lldb/source/Host/common/MainLoop.cpp:158:10:
error: no viable conversion from returned value of type 'int' to function
return type 'sigset_t' (aka '__sigset_t')
return 0;
^
/usr/include/bits/sigset.h:27:9: note: candidate constructor (the implicit
copy constructor) not viable: no known conversion from 'int' to 'const
__sigset_t &' for 1st argument
typedef struct
^
/usr/include/bits/sigset.h:27:9: note: candidate constructor (the implicit
move constructor) not viable: no known conversion from 'int' to '__sigset_t &&'
for 1st argument
1 error generated.
So I simply changed the return value, please review my patch and point out my
fault, thanks a lot!
Regards,
Leslie Zhai
Repository:
rL LLVM
https://reviews.llvm.org/D32787
Files:
source/Host/common/MainLoop.cpp
Index: source/Host/common/MainLoop.cpp
===
--- source/Host/common/MainLoop.cpp
+++ source/Host/common/MainLoop.cpp
@@ -155,7 +155,9 @@
sigset_t MainLoop::RunImpl::get_sigmask() {
#if SIGNAL_POLLING_UNSUPPORTED
- return 0;
+ sigset_t sigmask;
+ memset(sigmask.__val, 0, _SIGSET_NWORDS);
+ return sigmask;
#else
sigset_t sigmask;
int ret = pthread_sigmask(SIG_SETMASK, nullptr, &sigmask);
Index: source/Host/common/MainLoop.cpp
===
--- source/Host/common/MainLoop.cpp
+++ source/Host/common/MainLoop.cpp
@@ -155,7 +155,9 @@
sigset_t MainLoop::RunImpl::get_sigmask() {
#if SIGNAL_POLLING_UNSUPPORTED
- return 0;
+ sigset_t sigmask;
+ memset(sigmask.__val, 0, _SIGSET_NWORDS);
+ return sigmask;
#else
sigset_t sigmask;
int ret = pthread_sigmask(SIG_SETMASK, nullptr, &sigmask);
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32421: Fix segfault resulting from empty print prompt
xiaobai added a comment.
Over the weekend I dug into this further. It looks like the environment I found
this bug in didn't have C++11 support and was using `std::string::length()`,
which tries to perform a memory read where it's not supposed to, resulting in a
segfault.
On my friend's Ubuntu server, it used `std::basic_string::length()` (since I
had C++11 support). By sheer luck, `std::basic_string::length()` read a memory
location that was indeed mapped but contained unrelated data. This isn't a
breaking behavior since we use the result mod 80 to calculate `toColumn`, and
immediately after the `MoveCursor` call we `fprintf("\n")`. I still think this
is an issue.
As for the pexpect test, I tried to make it as simple as possible while
maintaining the general style/feel of the test you suggested I look at. It
passes when I run it with `dotest.py`, but I'm not sure if it should do more.
I'm interested to see what you think.
https://reviews.llvm.org/D32421
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
