[Lldb-commits] [PATCH] D32421: Fix segfault resulting from empty print prompt
xiaobai updated this revision to Diff 97553.
xiaobai added a comment.
Updating per @labath's suggestions
https://reviews.llvm.org/D32421
Files:
packages/Python/lldbsuite/test/functionalities/print/TestPrintEmptyExpressionList.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/functionalities/print/TestPrintEmptyExpressionList.py
===
--- /dev/null
+++
packages/Python/lldbsuite/test/functionalities/print/TestPrintEmptyExpressionList.py
@@ -0,0 +1,35 @@
+"""Test printing an empty list of expressions"""
+
+from __future__ import print_function
+
+import os
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+class PrintEmptyExpressionListCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def test_print_empty_list_expressions(self):
+"""Test printing an empty list of expressions"""
+import pexpect
+prompt = "(lldb) "
+
+# This is so the child is torn down after the test.
+self.child = pexpect.spawn(
+"%s %s" %
+(lldbtest_config.lldbExec, self.lldbOption))
+child = self.child
+
+# Turn on logging to see 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/functionalities/print/TestPrintEmptyExpressionList.py
===
--- /dev/null
+++ packages/Python/lldbsuite/test/functionalities/print/TestPrintEmptyExpressionList.py
@@ -0,0 +1,35 @@
+"""Test printing an empty list of expressions"""
+
+from __future__ import print_function
+
+import os
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+class PrintEmptyExpressionListCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def test_print_empty_list_expressions(self):
+"""Test printing an empty list of expressions"""
+import pexpect
+prompt = "(lldb) "
+
+# This is so the child is torn down after the test.
+self.child = pexpect.spawn(
+"%s %s" %
+(lldbtest_config.lldbExec, self.lldbOption))
+child = self.child
+
+# Turn on logging to see 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
Re: [Lldb-commits] [PATCH] D32522: Test case for the issue raised in D32271
Can you rewrite the exe path computation to use os.path.join so we're not
assuming posix syntax?
On Tue, May 2, 2017 at 11:11 PM vignesh balu via Phabricator via
lldb-commits wrote:
> vbalu updated this revision to Diff 97550.
> vbalu added a comment.
>
> Corrected the code. Now this test will fail without
> https://reviews.llvm.org/D32271 patch.
>
>
> 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 = './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 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 97550.
vbalu added a comment.
Corrected the code. Now this test will fail without
https://reviews.llvm.org/D32271 patch.
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 = './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 = './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] [lldb] r301993 - Fixed a bug where we did not properly use the complete versions of Objective-C classes.
Author: spyffe
Date: Tue May 2 19:41:43 2017
New Revision: 301993
URL: http://llvm.org/viewvc/llvm-project?rev=301993&view=rev
Log:
Fixed a bug where we did not properly use the complete versions of Objective-C
classes.
Also added a test case, thanks to Greg Clayton.
Added:
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/conflicting-definition/
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/conflicting-definition/Makefile
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/conflicting-definition/Test/
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/conflicting-definition/Test/Foo.h
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/conflicting-definition/Test/Test.h
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/conflicting-definition/Test/Test.m
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/conflicting-definition/TestConflictingDefinition.py
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/conflicting-definition/TestExt/
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/conflicting-definition/TestExt/Foo.h
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/conflicting-definition/TestExt/TestExt.h
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/conflicting-definition/TestExt/TestExt.m
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/conflicting-definition/main.m
Modified:
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp
Added:
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=301993&view=auto
==
---
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/conflicting-definition/Makefile
(added)
+++
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/conflicting-definition/Makefile
Tue May 2 19:41:43 2017
@@ -0,0 +1,24 @@
+LEVEL = ../../../make
+
+CFLAGS = -g -O0
+LDFLAGS = $(CFLAGS) -lobjc -framework Foundation
+
+all: a.out libTest.dylib libTestExt.dylib
+
+libTest.dylib: Test/Test.m
+ $(CC) $(CFLAGS) -I. -c -o Test.o Test/Test.m
+ $(CC) $(LDFLAGS) -shared -o libTest.dylib Test.o
+ dsymutil libTest.dylib
+
+libTestExt.dylib: TestExt/TestExt.m
+ $(CC) $(CFLAGS) -I. -c -o TestExt.o TestExt/TestExt.m
+ $(CC) $(LDFLAGS) -L. -lTest -shared -o libTestExt.dylib TestExt.o
+ dsymutil libTestExt.dylib
+
+a.out: main.m libTest.dylib libTestExt.dylib
+ $(CC) $(LDFLAGS) -I. -L. -lTest -lTestExt -o a.out main.m
+
+.PHONY: clean
+
+clean:
+ rm -rf *.dylib a.out *.o *.dSYM *.d
Added:
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/conflicting-definition/Test/Foo.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/objc/conflicting-definition/Test/Foo.h?rev=301993&view=auto
==
---
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/conflicting-definition/Test/Foo.h
(added)
+++
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/conflicting-definition/Test/Foo.h
Tue May 2 19:41:43 2017
@@ -0,0 +1,9 @@
+#ifndef __Foo_h__
+#define __Foo_h__
+
+typedef struct {
+float start;
+float duration;
+} CMTimeRange;
+
+#endif
Added:
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/conflicting-definition/Test/Test.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/objc/conflicting-definition/Test/Test.h?rev=301993&view=auto
==
---
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/conflicting-definition/Test/Test.h
(added)
+++
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/conflicting-definition/Test/Test.h
Tue May 2 19:41:43 2017
@@ -0,0 +1,10 @@
+#import
+#import
+
+@interface Test : NSObject {
+@public
+CMTimeRange _range;
+}
+- (void) doTest;
+@end
+
Added:
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/conflicting-definition/Test/Test.m
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/objc/conflicting-definition/Test/Test.m?rev=301993&view=auto
==
---
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/conflicting-definition/Test/Test.m
(added)
+++
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/conflicting-definition/Test/Test.m
Tue May 2 19:41:43 2017
@@ -0,0 +1,8 @@
+#import "Test.h"
+
+@implementation Test
+- (void) doTest {
+NSLog(@"-[Test doTest]");
+}
+@end
+
Added:
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/conflicting-definition/TestConflictingDefinition.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/objc/conflicting-definition/TestConflictingDefinition.py?re
[Lldb-commits] [PATCH] Fix Ubuntu build break with gcc 5.4
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] [PATCH] D32757: Add TaskMap for iterating a function over a set of integers
scott.smith added a comment. In https://reviews.llvm.org/D32757#743874, @clayborg wrote: > So I don't see where you moved all of the .Append functions. And if you did > your timings with them not being in there then your timings are off. finalize_fn calls Append on each source first, then calls Finalize. It might be hard to see because it's now a lambda that takes the src vector and dst NameToDIE as parameters. 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] [PATCH] D32757: Add TaskMap for iterating a function over a set of integers
clayborg added a comment. I know no one is using TaskRunner, but I would rather not remove it just yet. It has the possibility of being useful. Not in this case, but in general. I'd be interested in hearing what Pavel and Tamas think? None of this affects LLDB on Mac because all Darwin (macOS, iOS, tvOS, watchOS) have Apple accelerator tables emitted by default. If you really want to speed things up, at least when compiling with a new clang, we can change the compiler to emit the apple accelerator tables on all systems... 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] [PATCH] D32757: Add TaskMap for iterating a function over a set of integers
clayborg added a comment. So I don't see where you moved all of the .Append functions. And if you did your timings with them not being in there then your timings are off. 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
Re: [Lldb-commits] [PATCH] D32757: Add TaskMap for iterating a function over a set of integers
Then make it ready :-/
Why does LLDB need llvm::ThreadPool for this to work? I proposed a single
function that is not dependent on any particular instance of a thread pool.
template
void parallel_for_each(Range &&R, Func &&F) {
// call F(Index, *Iter) for every item in R.
}
std::vector Foos = { "a", "b", "c" };
void handle_foo(int N, const std::string &S) {}
llvm::parallel_for_each(Foos, handle_foo);
There's nothing that needs to be done here to make this ready for
llvm::ThreadPool, because all you have to do is use it.
Perhaps the function could create a llvm::ThreadPool on the stack to be
used for this one operation.
Perhaps llvm is willing to allow a single global thread pool to be created
for parallel operations, and entire library of parallel functions could be
added that use the same global thread pool.
Or maybe we could have llvm::initializeParallelThreadPool(unsigned
Concurrency) that specifies the number of threads to create and all
operations will use that global thread pool.
The point is, without even making an effort to try, we don't know what
issues will people will have or how hard it even is. It might end up being
trivial, and you would get a lot of valuable performance and safety
feedback from some very good experts on the subject.
I'm not stating an ultimatum that the only way this will go in is if it's
in LLVM, but I *am* stating that LLVM needs to be the starting point for
discussion here, and only after we discover (if we discover) that a
solution cannot work, we can revisit this in LLDB.
This is useful functionality that could be used everywhere, and I would
like to see due diligence done here.
On Tue, May 2, 2017 at 1:56 PM Scott Smith via Phabricator <
revi...@reviews.llvm.org> wrote:
> scott.smith added a comment.
>
> In https://reviews.llvm.org/D32757#743796, @zturner wrote:
>
> > s/instead of LLVM/instead of LLDB/
>
>
> I hear you, but IMO it's not ready for that yet.
>
> 1. It would depend on ThreadPool, but
> 2. LLDB hasn't switched to ThreadPool yet, because
> 3. I want to figure out how to incorporate tasks enqueuing tasks first.
>
> I don't want to commit a monolithic patch with all my changes (and I
> haven't developed them all yet), so instead I submit incremental
> improvements.
>
>
> 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] [PATCH] D32757: Add TaskMap for iterating a function over a set of integers
scott.smith added a comment. In https://reviews.llvm.org/D32757#743796, @zturner wrote: > s/instead of LLVM/instead of LLDB/ I hear you, but IMO it's not ready for that yet. 1. It would depend on ThreadPool, but 2. LLDB hasn't switched to ThreadPool yet, because 3. I want to figure out how to incorporate tasks enqueuing tasks first. I don't want to commit a monolithic patch with all my changes (and I haven't developed them all yet), so instead I submit incremental improvements. 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] [PATCH] D32757: Add TaskMap for iterating a function over a set of integers
zturner requested changes to this revision. zturner added a comment. This revision now requires changes to proceed. Not to sound like a broken record, but please try to put this in LLVM instead of LLVM. I suggested a convenient function signature earlier. 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] [PATCH] D32757: Add TaskMap for iterating a function over a set of integers
zturner added a comment. s/instead of LLVM/instead of LLDB/ 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] [PATCH] D32757: Add TaskMap for iterating a function over a set of integers
scott.smith updated this revision to Diff 97494.
scott.smith marked 2 inline comments as done.
scott.smith added a comment.
change name to TaskRunOverint
remove TaskRunner
Repository:
rL LLVM
https://reviews.llvm.org/D32757
Files:
include/lldb/Utility/TaskPool.h
source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
source/Utility/TaskPool.cpp
unittests/Utility/TaskPoolTest.cpp
Index: unittests/Utility/TaskPoolTest.cpp
===
--- unittests/Utility/TaskPoolTest.cpp
+++ unittests/Utility/TaskPoolTest.cpp
@@ -30,25 +30,14 @@
ASSERT_EQ(17, r[3]);
}
-TEST(TaskPoolTest, TaskRunner) {
- auto fn = [](int x) { return std::make_pair(x, x * x); };
-
- TaskRunner> tr;
- tr.AddTask(fn, 1);
- tr.AddTask(fn, 2);
- tr.AddTask(fn, 3);
- tr.AddTask(fn, 4);
-
- int count = 0;
- while (true) {
-auto f = tr.WaitForNextCompletedTask();
-if (!f.valid())
- break;
-
-++count;
-std::pair v = f.get();
-ASSERT_EQ(v.first * v.first, v.second);
- }
-
- ASSERT_EQ(4, count);
+TEST(TaskPoolTest, TaskMap) {
+ int data[4];
+ auto fn = [&data](int x) { data[x] = x * x; };
+
+ TaskMap(4, 1, fn);
+
+ ASSERT_EQ(data[0] == 0);
+ ASSERT_EQ(data[1] == 1);
+ ASSERT_EQ(data[2] == 4);
+ ASSERT_EQ(data[3] == 9);
}
Index: source/Utility/TaskPool.cpp
===
--- source/Utility/TaskPool.cpp
+++ source/Utility/TaskPool.cpp
@@ -73,3 +73,30 @@
f();
}
}
+
+void TaskMapOverInt(size_t size, size_t batch,
+std::function const & func)
+{
+ std::atomic idx{0};
+ size_t num_workers = std::min((size + batch - 1) / batch,
+std::thread::hardware_concurrency());
+
+ auto wrapper = [&idx, size, batch, &func]()
+ {
+while (true) {
+ size_t batch_start = idx.fetch_add(batch);
+ if (batch_start >= size)
+break;
+ size_t batch_end = std::min(batch_start + batch, size);
+ for (size_t i = batch_start; i < batch_end; i++)
+func(i);
+}
+ };
+
+ std::vector> futures;
+ futures.reserve(num_workers);
+ for (size_t i = 0; i < num_workers; i++)
+futures.push_back(TaskPool::AddTask(wrapper));
+ for (size_t i = 0; i < num_workers; i++)
+futures[i].wait();
+}
Index: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
===
--- source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -1946,7 +1946,8 @@
std::vector type_index(num_compile_units);
std::vector namespace_index(num_compile_units);
-std::vector clear_cu_dies(num_compile_units, false);
+// std::vector might be implemented using bit test-and-set, so use uint8_t instead.
+std::vector clear_cu_dies(num_compile_units, false);
auto parser_fn = [debug_info, &function_basename_index,
&function_fullname_index, &function_method_index,
&function_selector_index, &objc_class_selectors_index,
@@ -1963,22 +1964,18 @@
return cu_idx;
};
-auto extract_fn = [debug_info](uint32_t cu_idx) {
+auto extract_fn = [debug_info, &clear_cu_dies](uint32_t cu_idx) {
DWARFCompileUnit *dwarf_cu = debug_info->GetCompileUnitAtIndex(cu_idx);
if (dwarf_cu) {
// dwarf_cu->ExtractDIEsIfNeeded(false) will return zero if the
// DIEs for a compile unit have already been parsed.
-return std::make_pair(cu_idx, dwarf_cu->ExtractDIEsIfNeeded(false) > 1);
+if (dwarf_cu->ExtractDIEsIfNeeded(false) > 1)
+ clear_cu_dies[cu_idx] = true;
}
- return std::make_pair(cu_idx, false);
};
// Create a task runner that extracts dies for each DWARF compile unit in a
// separate thread
-TaskRunner> task_runner_extract;
-for (uint32_t cu_idx = 0; cu_idx < num_compile_units; ++cu_idx)
- task_runner_extract.AddTask(extract_fn, cu_idx);
-
//--
// First figure out which compile units didn't have their DIEs already
// parsed and remember this. If no DIEs were parsed prior to this index
@@ -1988,48 +1985,33 @@
// a DIE in one compile unit refers to another and the indexes accesses
// those DIEs.
//--
-while (true) {
- auto f = task_runner_extract.WaitForNextCompletedTask();
- if (!f.valid())
-break;
- unsigned cu_idx;
- bool clear;
- std::tie(cu_idx, clear) = f.get();
- clear_cu_dies[cu_idx] = clear;
-}
+TaskMapOverInt(num_compile_units, 1, extract_fn);
// Now create a task runner that can index each DWARF compile unit in a
// separate
// thread so we can index quickly.
-TaskRunner task_runner;
-for (uint32_t cu_idx = 0; cu_idx < num_compile_
[Lldb-commits] [PATCH] D32757: Add TaskMap for iterating a function over a set of integers
scott.smith marked 6 inline comments as done.
scott.smith added a comment.
IMO the vector append issue doesn't matter, because the very next thing we do
is sort. Sorting is more expensive than appending, so the append is noise.
Comment at: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:1994
-TaskRunner task_runner;
-for (uint32_t cu_idx = 0; cu_idx < num_compile_units; ++cu_idx)
- task_runner.AddTask(parser_fn, cu_idx);
-
-while (true) {
- std::future f = task_runner.WaitForNextCompletedTask();
- if (!f.valid())
-break;
- uint32_t cu_idx = f.get();
+TaskMap(num_compile_units, 1, parser_fn);
scott.smith wrote:
> clayborg wrote:
> > Note that we lost performance here. The old code would run:
> >
> > ```
> > while (true) {
> > std::future f = task_runner.WaitForNextCompletedTask();
> > // Do expensive work as soon as possible with any random task that
> > completes as soon as it completes.
> > ```
> >
> > Your current code says "wait to do all expensive work until I complete
> > everything and then do all of the expensive work".
> >
> >
> >
> >
> The following loop is not expensive, it's simple vector concatenation of
> fairly simple types. The actual slow work is Finalize(), which calls Sort().
>
> m_function_basename_index is of type NameDIE, which has a UniqueCStringMap
> member, which declared collection as std::vector.
>
> Though arguably the Append should be pushed down into the RunTasks below.
>
This takes <0.25s (out of a total of 15 seconds of runtime) when timing lldb
starting lldb (RelWithDebInfo build). That's for an aggregate of 14M+ names
being added to the vectors. IMO that should not block this change.
I also moved the append into RunTasks, just because we already have those
subtasks.
Comment at: source/Utility/TaskPool.cpp:77
+
+void TaskMap(size_t size, size_t batch, std::function const &
func)
+{
clayborg wrote:
> Is this named correctly? Maybe SerializedTaskMap? Or BatchedTaskMap?
TaskMapOverInt?
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] [PATCH] D32757: Add TaskMap for iterating a function over a set of integers
scott.smith added a comment.
I can make more measurements on this.
Comment at: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:1994
-TaskRunner task_runner;
-for (uint32_t cu_idx = 0; cu_idx < num_compile_units; ++cu_idx)
- task_runner.AddTask(parser_fn, cu_idx);
-
-while (true) {
- std::future f = task_runner.WaitForNextCompletedTask();
- if (!f.valid())
-break;
- uint32_t cu_idx = f.get();
+TaskMap(num_compile_units, 1, parser_fn);
clayborg wrote:
> Note that we lost performance here. The old code would run:
>
> ```
> while (true) {
> std::future f = task_runner.WaitForNextCompletedTask();
> // Do expensive work as soon as possible with any random task that
> completes as soon as it completes.
> ```
>
> Your current code says "wait to do all expensive work until I complete
> everything and then do all of the expensive work".
>
>
>
>
The following loop is not expensive, it's simple vector concatenation of fairly
simple types. The actual slow work is Finalize(), which calls Sort().
m_function_basename_index is of type NameDIE, which has a UniqueCStringMap
member, which declared collection as std::vector.
Though arguably the Append should be pushed down into the RunTasks below.
Comment at: source/Utility/TaskPool.cpp:100
+ for (size_t i = 0; i < est_batches; i++)
+futures[i].wait();
+}
clayborg wrote:
> TaskRunner is smart in the way it runs things: it lets you run N things and
> get each item as it completes. This implementation, if read it correctly,
> will serialize everything. So if you have 100 items to do and item at index 0
> takes 200 seconds to complete, and items 1 - 99 take 1ms to complete, you
> will need to wait for task 0 to complete before you can start parsing the
> data. This will slow down the DWARF parser if you switch over to this.
If items 1-99 complete quickly, there isn't much advantage to handling their
output before handling the output of item 0, since item 0 is likely to produce
more output than 1-99 combined.
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] [PATCH] D32757: Add TaskMap for iterating a function over a set of integers
clayborg added a comment. In https://reviews.llvm.org/D32757#743669, @scott.smith wrote: > In https://reviews.llvm.org/D32757#743657, @clayborg wrote: > > > In https://reviews.llvm.org/D32757#743567, @scott.smith wrote: > > > > > IMO, this is a simpler interface than TaskRunner. Also, after this, > > > there are no users of TaskRunner left. Should I just delete them? > > > > > > I think you might not have understood TaskRunner's real benefits. It is > > smart in the way it runs things: it lets you run N things and get each item > > **as soon as it completes**. The TaskMap will serialize everything. So if > > you have 100 items to do and item 0 takes 200 seconds to complete, and > > items 1 - 99 take 1ms to complete, you will need to wait for task 0 to > > complete before you can start parsing the data. This will slow down the > > DWARF parser if you switch over to this. TaskRunner should not be deleted > > as it has a very specific purpose. Your TaskMap works fine for one case, > > but not in the other. > > > That may provide a benefit on machines with a few cores, but doesn't really > help when you have 40+ cores. Granted, the average laptop has 4 cores/8 > hyperthreads. It is no different on any machine with any number of cores. TaskRunner will be faster in all cases for the second DWARF loop. It is also nice to be able to consume the information as it comes in, so TaskRunner is needed. I do like the TaskMap idea to make things batch-able so I think they both add value. > > >>> I did this change to help parallel symbol demangling (to come in a separate >>> patch). Rather than have the symbol demangler use batching, etc, I thought >>> it should be a higher level function. >> >> Make sure this is a win before switching demangling over to using threads. I >> tried to improve performance on demangling before and I got worse >> performance on MacOS when we tried it because all of the malloc contention >> and threading overhead. > > It is on my machine, but maybe not on other machines. That would be > unfortunate. I'm guessing I shouldn't add go ahead and add jemalloc/tcmalloc > to work around poor a MacOS malloc? haha. lol. If it does improve things and if it integrates nicely with all of the malloc tools on MacOS, I wouldn't be opposed. I don't know much about jemalloc/tcmalloc, but if there are perf wins to be had that don't hose over the malloc zone/block iterations I am all for it! 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] [PATCH] D32757: Add TaskMap for iterating a function over a set of integers
zturner requested changes to this revision.
zturner added a comment.
I would suggest putting this in LLVM, as something liek this:
namespace llvm {
template
void parallel_apply(Range &&R, Func &&F) {
// enqueue items here.
// wait for all tasks to complete.
}
}
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] [PATCH] D32757: Add TaskMap for iterating a function over a set of integers
scott.smith added a comment. In https://reviews.llvm.org/D32757#743657, @clayborg wrote: > In https://reviews.llvm.org/D32757#743567, @scott.smith wrote: > > > IMO, this is a simpler interface than TaskRunner. Also, after this, there > > are no users of TaskRunner left. Should I just delete them? > > > I think you might not have understood TaskRunner's real benefits. It is smart > in the way it runs things: it lets you run N things and get each item **as > soon as it completes**. The TaskMap will serialize everything. So if you have > 100 items to do and item 0 takes 200 seconds to complete, and items 1 - 99 > take 1ms to complete, you will need to wait for task 0 to complete before you > can start parsing the data. This will slow down the DWARF parser if you > switch over to this. TaskRunner should not be deleted as it has a very > specific purpose. Your TaskMap works fine for one case, but not in the other. That may provide a benefit on machines with a few cores, but doesn't really help when you have 40+ cores. Granted, the average laptop has 4 cores/8 hyperthreads. >> I did this change to help parallel symbol demangling (to come in a separate >> patch). Rather than have the symbol demangler use batching, etc, I thought >> it should be a higher level function. > > Make sure this is a win before switching demangling over to using threads. I > tried to improve performance on demangling before and I got worse performance > on MacOS when we tried it because all of the malloc contention and threading > overhead. It is on my machine, but maybe not on other machines. That would be unfortunate. I'm guessing I shouldn't add go ahead and add jemalloc/tcmalloc to work around poor a MacOS malloc? haha. 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] [PATCH] D32757: Add TaskMap for iterating a function over a set of integers
clayborg added a comment. And note in the DWARF parser you can't add the expensive code that aggregates all of the data into the SymbolFileDWARF into "parser_fn" because only on thread can be putting stuff into SymbolFileDWARF at a time. 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] [PATCH] D32757: Add TaskMap for iterating a function over a set of integers
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
In https://reviews.llvm.org/D32757#743567, @scott.smith wrote:
> IMO, this is a simpler interface than TaskRunner. Also, after this, there
> are no users of TaskRunner left. Should I just delete them?
I think you might not have understood TaskRunner's real benefits. It is smart
in the way it runs things: it lets you run N things and get each item **as soon
as it completes**. The TaskMap will serialize everything. So if you have 100
items to do and item 0 takes 200 seconds to complete, and items 1 - 99 take 1ms
to complete, you will need to wait for task 0 to complete before you can start
parsing the data. This will slow down the DWARF parser if you switch over to
this. TaskRunner should not be deleted as it has a very specific purpose. Your
TaskMap works fine for one case, but not in the other.
> I did this change to help parallel symbol demangling (to come in a separate
> patch). Rather than have the symbol demangler use batching, etc, I thought
> it should be a higher level function.
Make sure this is a win before switching demangling over to using threads. I
tried to improve performance on demangling before and I got worse performance
on MacOS when we tried it because all of the malloc contention and threading
overhead.
Comment at: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:1988
//--
-while (true) {
- auto f = task_runner_extract.WaitForNextCompletedTask();
- if (!f.valid())
-break;
- unsigned cu_idx;
- bool clear;
- std::tie(cu_idx, clear) = f.get();
- clear_cu_dies[cu_idx] = clear;
-}
+TaskMap(num_compile_units, 1, extract_fn);
This replacement is ok, since no expensive work is being done in the while loop
that did the task_runner_extract.WaitForNextCompletedTask();.
Comment at: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:1994
-TaskRunner task_runner;
-for (uint32_t cu_idx = 0; cu_idx < num_compile_units; ++cu_idx)
- task_runner.AddTask(parser_fn, cu_idx);
-
-while (true) {
- std::future f = task_runner.WaitForNextCompletedTask();
- if (!f.valid())
-break;
- uint32_t cu_idx = f.get();
+TaskMap(num_compile_units, 1, parser_fn);
Note that we lost performance here. The old code would run:
```
while (true) {
std::future f = task_runner.WaitForNextCompletedTask();
// Do expensive work as soon as possible with any random task that
completes as soon as it completes.
```
Your current code says "wait to do all expensive work until I complete
everything and then do all of the expensive work".
Comment at: source/Utility/TaskPool.cpp:77
+
+void TaskMap(size_t size, size_t batch, std::function const &
func)
+{
Is this named correctly? Maybe SerializedTaskMap? Or BatchedTaskMap?
Comment at: source/Utility/TaskPool.cpp:100
+ for (size_t i = 0; i < est_batches; i++)
+futures[i].wait();
+}
TaskRunner is smart in the way it runs things: it lets you run N things and get
each item as it completes. This implementation, if read it correctly, will
serialize everything. So if you have 100 items to do and item at index 0 takes
200 seconds to complete, and items 1 - 99 take 1ms to complete, you will need
to wait for task 0 to complete before you can start parsing the data. This will
slow down the DWARF parser if you switch over to this.
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] [PATCH] D32757: Add TaskMap for iterating a function over a set of integers
scott.smith added a comment. IMO, this is a simpler interface than TaskRunner. Also, after this, there are no users of TaskRunner left. Should I just delete them? I did this change to help parallel symbol demangling (to come in a separate patch). Rather than have the symbol demangler use batching, etc, I thought it should be a higher level function. 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] [PATCH] D32757: Add TaskMap for iterating a function over a set of integers
scott.smith created this revision.
Many parallel tasks just want to iterate over all the possible numbers from 0
to N-1. Rather than enqueue N work items, instead just "map" the function
across the requested integer space.
Repository:
rL LLVM
https://reviews.llvm.org/D32757
Files:
include/lldb/Utility/TaskPool.h
source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
source/Utility/TaskPool.cpp
unittests/Utility/TaskPoolTest.cpp
Index: unittests/Utility/TaskPoolTest.cpp
===
--- unittests/Utility/TaskPoolTest.cpp
+++ unittests/Utility/TaskPoolTest.cpp
@@ -52,3 +52,15 @@
ASSERT_EQ(4, count);
}
+
+TEST(TaskPoolTest, TaskMap) {
+ int data[4];
+ auto fn = [&data](int x) { data[x] = x * x; };
+
+ TaskMap(4, 1, fn);
+
+ ASSERT_EQ(data[0] == 0);
+ ASSERT_EQ(data[1] == 1);
+ ASSERT_EQ(data[2] == 4);
+ ASSERT_EQ(data[3] == 9);
+}
Index: source/Utility/TaskPool.cpp
===
--- source/Utility/TaskPool.cpp
+++ source/Utility/TaskPool.cpp
@@ -73,3 +73,29 @@
f();
}
}
+
+void TaskMap(size_t size, size_t batch, std::function const & func)
+{
+ std::atomic idx{0};
+ size_t est_batches = std::min((size + batch - 1) / batch,
+std::thread::hardware_concurrency());
+
+ auto wrapper = [&idx, size, batch, &func]()
+ {
+while (true) {
+ size_t batch_start = idx.fetch_add(batch);
+ if (batch_start >= size)
+break;
+ size_t batch_end = std::min(batch_start + batch, size);
+ for (size_t i = batch_start; i < batch_end; i++)
+func(i);
+}
+ };
+
+ std::vector> futures;
+ futures.reserve(est_batches);
+ for (size_t i = 0; i < est_batches; i++)
+futures.push_back(TaskPool::AddTask(wrapper));
+ for (size_t i = 0; i < est_batches; i++)
+futures[i].wait();
+}
Index: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
===
--- source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -1946,7 +1946,8 @@
std::vector type_index(num_compile_units);
std::vector namespace_index(num_compile_units);
-std::vector clear_cu_dies(num_compile_units, false);
+// std::vector might be implemented using bit test-and-set, so use uint8_t instead.
+std::vector clear_cu_dies(num_compile_units, false);
auto parser_fn = [debug_info, &function_basename_index,
&function_fullname_index, &function_method_index,
&function_selector_index, &objc_class_selectors_index,
@@ -1963,22 +1964,18 @@
return cu_idx;
};
-auto extract_fn = [debug_info](uint32_t cu_idx) {
+auto extract_fn = [debug_info, &clear_cu_dies](uint32_t cu_idx) {
DWARFCompileUnit *dwarf_cu = debug_info->GetCompileUnitAtIndex(cu_idx);
if (dwarf_cu) {
// dwarf_cu->ExtractDIEsIfNeeded(false) will return zero if the
// DIEs for a compile unit have already been parsed.
-return std::make_pair(cu_idx, dwarf_cu->ExtractDIEsIfNeeded(false) > 1);
+if (dwarf_cu->ExtractDIEsIfNeeded(false) > 1)
+ clear_cu_dies[cu_idx] = true;
}
- return std::make_pair(cu_idx, false);
};
// Create a task runner that extracts dies for each DWARF compile unit in a
// separate thread
-TaskRunner> task_runner_extract;
-for (uint32_t cu_idx = 0; cu_idx < num_compile_units; ++cu_idx)
- task_runner_extract.AddTask(extract_fn, cu_idx);
-
//--
// First figure out which compile units didn't have their DIEs already
// parsed and remember this. If no DIEs were parsed prior to this index
@@ -1988,30 +1985,15 @@
// a DIE in one compile unit refers to another and the indexes accesses
// those DIEs.
//--
-while (true) {
- auto f = task_runner_extract.WaitForNextCompletedTask();
- if (!f.valid())
-break;
- unsigned cu_idx;
- bool clear;
- std::tie(cu_idx, clear) = f.get();
- clear_cu_dies[cu_idx] = clear;
-}
+TaskMap(num_compile_units, 1, extract_fn);
// Now create a task runner that can index each DWARF compile unit in a
// separate
// thread so we can index quickly.
-TaskRunner task_runner;
-for (uint32_t cu_idx = 0; cu_idx < num_compile_units; ++cu_idx)
- task_runner.AddTask(parser_fn, cu_idx);
-
-while (true) {
- std::future f = task_runner.WaitForNextCompletedTask();
- if (!f.valid())
-break;
- uint32_t cu_idx = f.get();
+TaskMap(num_compile_units, 1, parser_fn);
+for (uint32_t cu_idx = 0; cu_idx < num_compile_units; ++cu_idx) {
m_function_basename_index.Append(function_basename_index[cu_idx]);
[Lldb-commits] [PATCH] D32753: MainLoop: Add unit tests
labath created this revision.
Herald added a subscriber: mgorny.
This adds a couple of unit tests to the MainLoop class. To get the
kqueue based version of the signal handling passing, I needed to
modify the implementation a bit to make the queue object persistent.
Otherwise, only the signals which are send during the Run call would get
processed, which did not match the ppoll behaviour.
I also took the opportunity to remove the ForEach template functions and
replace them with something more reasonable.
https://reviews.llvm.org/D32753
Files:
include/lldb/Host/MainLoop.h
source/Host/common/MainLoop.cpp
unittests/Host/CMakeLists.txt
unittests/Host/MainLoopTest.cpp
Index: unittests/Host/MainLoopTest.cpp
===
--- /dev/null
+++ unittests/Host/MainLoopTest.cpp
@@ -0,0 +1,120 @@
+//===-- MainLoopTest.cpp *- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "lldb/Host/MainLoop.h"
+#include "lldb/Host/common/TCPSocket.h"
+#include "gtest/gtest.h"
+#include
+
+using namespace lldb_private;
+
+namespace {
+class MainLoopTest : public testing::Test {
+public:
+ static void SetUpTestCase() {
+#ifdef _MSC_VER
+WSADATA data;
+ASSERT_EQ(0, WSAStartup(MAKEWORD(2, 2), &data));
+#endif
+ }
+
+ static void TearDownTestCase() {
+#ifdef _MSC_VER
+ASSERT_EQ(0, WSACleanup());
+#endif
+ }
+
+ void SetUp() override {
+bool child_processes_inherit = false;
+Error error;
+std::unique_ptr listen_socket_up(
+new TCPSocket(true, child_processes_inherit));
+ASSERT_TRUE(error.Success());
+error = listen_socket_up->Listen("localhost:0", 5);
+ASSERT_TRUE(error.Success());
+
+Socket *accept_socket;
+std::future accept_error = std::async(std::launch::async, [&] {
+ return listen_socket_up->Accept(accept_socket);
+});
+
+std::unique_ptr connect_socket_up(
+new TCPSocket(true, child_processes_inherit));
+error = connect_socket_up->Connect(
+llvm::formatv("localhost:{0}", listen_socket_up->GetLocalPortNumber())
+.str());
+ASSERT_TRUE(error.Success());
+ASSERT_TRUE(accept_error.get().Success());
+
+callback_count = 0;
+socketpair[0] = std::move(connect_socket_up);
+socketpair[1].reset(accept_socket);
+ }
+
+ void TearDown() override {
+socketpair[0].reset();
+socketpair[1].reset();
+ }
+
+protected:
+ MainLoop::Callback make_callback() {
+return [&](MainLoopBase &loop) {
+ ++callback_count;
+ loop.RequestTermination();
+};
+ }
+ std::shared_ptr socketpair[2];
+ unsigned callback_count;
+};
+} // namespace
+
+TEST_F(MainLoopTest, ReadObject) {
+ char X = 'X';
+ size_t len = sizeof(X);
+ ASSERT_TRUE(socketpair[0]->Write(&X, len).Success());
+
+ MainLoop loop;
+
+ Error error;
+ auto handle = loop.RegisterReadObject(socketpair[1], make_callback(), error);
+ ASSERT_TRUE(error.Success());
+ ASSERT_TRUE(handle);
+ ASSERT_TRUE(loop.Run().Success());
+ ASSERT_EQ(1u, callback_count);
+}
+
+TEST_F(MainLoopTest, TerminatesImmediately) {
+ char X = 'X';
+ size_t len = sizeof(X);
+ ASSERT_TRUE(socketpair[0]->Write(&X, len).Success());
+ ASSERT_TRUE(socketpair[1]->Write(&X, len).Success());
+
+ MainLoop loop;
+ Error error;
+ auto handle0 = loop.RegisterReadObject(socketpair[0], make_callback(), error);
+ ASSERT_TRUE(error.Success());
+ auto handle1 = loop.RegisterReadObject(socketpair[1], make_callback(), error);
+ ASSERT_TRUE(error.Success());
+
+ ASSERT_TRUE(loop.Run().Success());
+ ASSERT_EQ(1u, callback_count);
+}
+
+#ifdef LLVM_ON_UNIX
+TEST_F(MainLoopTest, Signal) {
+ MainLoop loop;
+ Error error;
+
+ auto handle = loop.RegisterSignal(SIGUSR1, make_callback(), error);
+ ASSERT_TRUE(error.Success());
+ kill(getpid(), SIGUSR1);
+ ASSERT_TRUE(loop.Run().Success());
+ ASSERT_EQ(1u, callback_count);
+}
+#endif
Index: unittests/Host/CMakeLists.txt
===
--- unittests/Host/CMakeLists.txt
+++ unittests/Host/CMakeLists.txt
@@ -1,6 +1,7 @@
set (FILES
FileSpecTest.cpp
FileSystemTest.cpp
+ MainLoopTest.cpp
SocketAddressTest.cpp
SocketTest.cpp
SymbolsTest.cpp
Index: source/Host/common/MainLoop.cpp
===
--- source/Host/common/MainLoop.cpp
+++ source/Host/common/MainLoop.cpp
@@ -65,92 +65,72 @@
class MainLoop::RunImpl {
public:
- // TODO: Use llvm::Expected
- static std::unique_ptr Create(MainLoop &loop, Error &error);
- ~RunImpl();
+ RunImpl(MainLoop &loop);
+ ~RunImpl() = default;
Error Poll();
-
- template void ForEachReadFD(F &&f);
- template void ForEachSignal(F &&f);
+ v
[Lldb-commits] [PATCH] D32708: Check for lack of C++ context first when demangling
scott.smith added a comment. In https://reviews.llvm.org/D32708#743161, @labath wrote: > I am having trouble applying this. Do you need to rebase or something? It was based on another commit that you committed for me, but committed after trying to commit this one. It should apply now that you committed https://reviews.llvm.org/D32316. Repository: rL LLVM https://reviews.llvm.org/D32708 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32168: [LLDB][MIPS] Fix TestStepOverBreakpoint.py failure
jingham accepted this revision. jingham added a comment. This revision is now accepted and ready to land. Looks good, thanks! https://reviews.llvm.org/D32168 ___ 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
labath accepted this revision. labath added a comment. This revision is now accepted and ready to land. I don't like either of the solutions too much, but this one is at least less code. :) https://reviews.llvm.org/D32719 ___ 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
fjricci updated this revision to Diff 97447.
fjricci added a comment.
Move checks into cpp files
https://reviews.llvm.org/D32719
Files:
packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/main.cpp
packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/mpx_bound_violation/main.cpp
Index:
packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/mpx_bound_violation/main.cpp
===
---
packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/mpx_bound_violation/main.cpp
+++
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:
packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/main.cpp
===
---
packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/main.cpp
+++
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: packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/mpx_bound_violation/main.cpp
===
--- packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/mpx_bound_violation/main.cpp
+++ 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: packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/main.cpp
===
--- packages/Python/lldbsuite/test/functionalities/register/intel_xtended_registers/main.cpp
+++ 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;
___
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
fjricci added a comment. Yeah, that works too, just wasn't sure which way was preferred. https://reviews.llvm.org/D32719 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r301918 - Android.rules: set "ar" path correctly
Author: labath Date: Tue May 2 08:14:45 2017 New Revision: 301918 URL: http://llvm.org/viewvc/llvm-project?rev=301918&view=rev Log: Android.rules: set "ar" path correctly Modified: lldb/trunk/packages/Python/lldbsuite/test/make/Android.rules Modified: lldb/trunk/packages/Python/lldbsuite/test/make/Android.rules URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/make/Android.rules?rev=301918&r1=301917&r2=301918&view=diff == --- lldb/trunk/packages/Python/lldbsuite/test/make/Android.rules (original) +++ lldb/trunk/packages/Python/lldbsuite/test/make/Android.rules Tue May 2 08:14:45 2017 @@ -63,6 +63,7 @@ endif GCC_TOOLCHAIN = $(NDK_ROOT)/toolchains/$(TOOLCHAIN_DIR)/prebuilt/$(HOST_TAG) OBJCOPY ?= $(GCC_TOOLCHAIN)/bin/$(TOOL_PREFIX)-objcopy +ARCHIVER ?= $(GCC_TOOLCHAIN)/bin/$(TOOL_PREFIX)-ar ifeq "$(findstring clang,$(CC))" "clang" ARCH_CFLAGS += -target $(TRIPLE) -gcc-toolchain $(GCC_TOOLCHAIN) ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r301917 - ObjectFileELF: Fix symbol lookup in bss section
Author: labath
Date: Tue May 2 07:40:31 2017
New Revision: 301917
URL: http://llvm.org/viewvc/llvm-project?rev=301917&view=rev
Log:
ObjectFileELF: Fix symbol lookup in bss section
Summary:
If we have symbol information in a separate file, we need to be very
careful about presenting a unified section view of module to the rest of
the debugger. ObjectFileELF had code to handle that, but it was being
overly cautious -- the section->GetFileSize()!=0 meant that the
unification would fail for sections which do not occupy any space in the
object file (e.g., .bss). In my case, that manifested itself as not
being able to display the values of .bss variables properly as the
section associated with the variable did not have it's load address set
(because it was not present in the unified section list).
I test this by making sure the unified section list and the variables
refer to the same section.
Reviewers: eugene, zturner
Subscribers: tberghammer, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D32434
Added:
lldb/trunk/unittests/ObjectFile/ELF/Inputs/
lldb/trunk/unittests/ObjectFile/ELF/Inputs/sections-resolve-consistently.yaml
lldb/trunk/unittests/ObjectFile/ELF/TestObjectFileELF.cpp
Modified:
lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
lldb/trunk/unittests/ObjectFile/ELF/CMakeLists.txt
Modified: lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp?rev=301917&r1=301916&r2=301917&view=diff
==
--- lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp (original)
+++ lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp Tue May 2
07:40:31 2017
@@ -2418,7 +2418,7 @@ unsigned ObjectFileELF::ParseSymbols(Sym
.emplace(sect_name.GetCString(),
module_section_list->FindSectionByName(sect_name))
.first;
- if (section_it->second && section_it->second->GetFileSize())
+ if (section_it->second)
symbol_section_sp = section_it->second;
}
Modified: lldb/trunk/unittests/ObjectFile/ELF/CMakeLists.txt
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/ObjectFile/ELF/CMakeLists.txt?rev=301917&r1=301916&r2=301917&view=diff
==
--- lldb/trunk/unittests/ObjectFile/ELF/CMakeLists.txt (original)
+++ lldb/trunk/unittests/ObjectFile/ELF/CMakeLists.txt Tue May 2 07:40:31 2017
@@ -1,7 +1,17 @@
add_lldb_unittest(ObjectFileELFTests
TestELFHeader.cpp
+ TestObjectFileELF.cpp
LINK_LIBS
lldbPluginObjectFileELF
+lldbPluginSymbolVendorELF
lldbCore
)
+
+add_dependencies(ObjectFileELFTests yaml2obj)
+add_definitions(-DYAML2OBJ="$")
+
+set(test_inputs
+ sections-resolve-consistently.yaml
+ )
+add_unittest_inputs(ObjectFileELFTests "${test_inputs}")
Added:
lldb/trunk/unittests/ObjectFile/ELF/Inputs/sections-resolve-consistently.yaml
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/ObjectFile/ELF/Inputs/sections-resolve-consistently.yaml?rev=301917&view=auto
==
---
lldb/trunk/unittests/ObjectFile/ELF/Inputs/sections-resolve-consistently.yaml
(added)
+++
lldb/trunk/unittests/ObjectFile/ELF/Inputs/sections-resolve-consistently.yaml
Tue May 2 07:40:31 2017
@@ -0,0 +1,50 @@
+--- !ELF
+FileHeader:
+ Class: ELFCLASS64
+ Data:ELFDATA2LSB
+ Type:ET_EXEC
+ Machine: EM_X86_64
+ Entry: 0x00400180
+Sections:
+ - Name:.note.gnu.build-id
+Type:SHT_NOTE
+Flags: [ SHF_ALLOC ]
+Address: 0x00400158
+AddressAlign:0x0004
+Content:
040014000300474E55003F3EC29E3FD83E49D18C4D49CD8A730CC13117B6
+ - Name:.text
+Type:SHT_PROGBITS
+Flags: [ SHF_ALLOC, SHF_EXECINSTR ]
+Address: 0x00400180
+AddressAlign:0x0010
+Content: 554889E58B042500106000890425041060005DC3
+ - Name:.data
+Type:SHT_PROGBITS
+Flags: [ SHF_WRITE, SHF_ALLOC ]
+Address: 0x00601000
+AddressAlign:0x0004
+Content: 2F00
+ - Name:.bss
+Type:SHT_NOBITS
+Flags: [ SHF_WRITE, SHF_ALLOC ]
+Address: 0x00601004
+AddressAlign:0x0004
+Size:0x0004
+Symbols:
+ Global:
+- Name:Y
+ Type:STT_OBJECT
+ Section: .data
+ Value: 0x00601000
+ Size:0x0004
+- Name:_start
+ Type:STT_FUNC
+ Sect
[Lldb-commits] [PATCH] D32434: ObjectFileELF: Fix symbol lookup in bss section
This revision was automatically updated to reflect the committed changes.
Closed by commit rL301917: ObjectFileELF: Fix symbol lookup in bss section
(authored by labath).
Changed prior to commit:
https://reviews.llvm.org/D32434?vs=96541&id=97435#toc
Repository:
rL LLVM
https://reviews.llvm.org/D32434
Files:
lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
lldb/trunk/unittests/ObjectFile/ELF/CMakeLists.txt
lldb/trunk/unittests/ObjectFile/ELF/Inputs/sections-resolve-consistently.yaml
lldb/trunk/unittests/ObjectFile/ELF/TestObjectFileELF.cpp
Index: lldb/trunk/unittests/ObjectFile/ELF/Inputs/sections-resolve-consistently.yaml
===
--- lldb/trunk/unittests/ObjectFile/ELF/Inputs/sections-resolve-consistently.yaml
+++ lldb/trunk/unittests/ObjectFile/ELF/Inputs/sections-resolve-consistently.yaml
@@ -0,0 +1,50 @@
+--- !ELF
+FileHeader:
+ Class: ELFCLASS64
+ Data:ELFDATA2LSB
+ Type:ET_EXEC
+ Machine: EM_X86_64
+ Entry: 0x00400180
+Sections:
+ - Name:.note.gnu.build-id
+Type:SHT_NOTE
+Flags: [ SHF_ALLOC ]
+Address: 0x00400158
+AddressAlign:0x0004
+Content: 040014000300474E55003F3EC29E3FD83E49D18C4D49CD8A730CC13117B6
+ - Name:.text
+Type:SHT_PROGBITS
+Flags: [ SHF_ALLOC, SHF_EXECINSTR ]
+Address: 0x00400180
+AddressAlign:0x0010
+Content: 554889E58B042500106000890425041060005DC3
+ - Name:.data
+Type:SHT_PROGBITS
+Flags: [ SHF_WRITE, SHF_ALLOC ]
+Address: 0x00601000
+AddressAlign:0x0004
+Content: 2F00
+ - Name:.bss
+Type:SHT_NOBITS
+Flags: [ SHF_WRITE, SHF_ALLOC ]
+Address: 0x00601004
+AddressAlign:0x0004
+Size:0x0004
+Symbols:
+ Global:
+- Name:Y
+ Type:STT_OBJECT
+ Section: .data
+ Value: 0x00601000
+ Size:0x0004
+- Name:_start
+ Type:STT_FUNC
+ Section: .text
+ Value: 0x00400180
+ Size:0x0014
+- Name:X
+ Type:STT_OBJECT
+ Section: .bss
+ Value: 0x00601004
+ Size:0x0004
+...
Index: lldb/trunk/unittests/ObjectFile/ELF/TestObjectFileELF.cpp
===
--- lldb/trunk/unittests/ObjectFile/ELF/TestObjectFileELF.cpp
+++ lldb/trunk/unittests/ObjectFile/ELF/TestObjectFileELF.cpp
@@ -0,0 +1,105 @@
+//===-- TestObjectFileELF.cpp ---*- C++ -*-===//
+//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "Plugins/ObjectFile/ELF/ObjectFileELF.h"
+#include "lldb/Core/Module.h"
+#include "lldb/Core/ModuleSpec.h"
+#include "lldb/Core/Section.h"
+#include "lldb/Host/HostInfo.h"
+#include "llvm/Support/FileUtilities.h"
+#include "llvm/Support/Path.h"
+#include "llvm/Support/Program.h"
+#include "llvm/Support/raw_ostream.h"
+#include "gtest/gtest.h"
+
+#include "Plugins/SymbolVendor/ELF/SymbolVendorELF.h"
+
+extern const char *TestMainArgv0;
+
+using namespace lldb_private;
+using namespace lldb;
+
+class ObjectFileELFTest : public testing::Test {
+public:
+ void SetUp() override {
+HostInfo::Initialize();
+ObjectFileELF::Initialize();
+SymbolVendorELF::Initialize();
+
+m_inputs_folder = llvm::sys::path::parent_path(TestMainArgv0);
+llvm::sys::path::append(m_inputs_folder, "Inputs");
+llvm::sys::fs::make_absolute(m_inputs_folder);
+ }
+
+ void TearDown() override {
+SymbolVendorELF::Terminate();
+ObjectFileELF::Terminate();
+HostInfo::Terminate();
+ }
+
+protected:
+ llvm::SmallString<128> m_inputs_folder;
+};
+
+#define ASSERT_NO_ERROR(x) \
+ if (std::error_code ASSERT_NO_ERROR_ec = x) {\
+llvm::SmallString<128> MessageStorage; \
+llvm::raw_svector_ostream Message(MessageStorage); \
+Message << #x ": did not return errc::success.\n" \
+<< "error number: " << ASSERT_NO_ERROR_ec.value() << "\n" \
+<< "error message: " << ASSERT_NO_ERROR_ec.message() << "\n"; \
+GTEST_FATAL_FAILURE_(MessageStorage.c_str());
[Lldb-commits] [PATCH] D32316: Change UniqueCStringMap to use ConstString as the key
This revision was automatically updated to reflect the committed changes.
Closed by commit rL301908: Change UniqueCStringMap to use ConstString as the
key (authored by labath).
Changed prior to commit:
https://reviews.llvm.org/D32316?vs=96629&id=97417#toc
Repository:
rL LLVM
https://reviews.llvm.org/D32316
Files:
lldb/trunk/include/lldb/Core/UniqueCStringMap.h
lldb/trunk/include/lldb/Symbol/ObjectFile.h
lldb/trunk/source/Interpreter/OptionValueEnumeration.cpp
lldb/trunk/source/Interpreter/OptionValueProperties.cpp
lldb/trunk/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.h
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/NameToDIE.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/NameToDIE.h
lldb/trunk/source/Symbol/ClangASTContext.cpp
lldb/trunk/source/Symbol/GoASTContext.cpp
lldb/trunk/source/Symbol/Symtab.cpp
Index: lldb/trunk/source/Symbol/GoASTContext.cpp
===
--- lldb/trunk/source/Symbol/GoASTContext.cpp
+++ lldb/trunk/source/Symbol/GoASTContext.cpp
@@ -598,33 +598,32 @@
static llvm::once_flag g_once_flag;
llvm::call_once(g_once_flag, []() {
// "void"
- g_type_map.Append(ConstString("void").GetStringRef(), eBasicTypeVoid);
+ g_type_map.Append(ConstString("void"), eBasicTypeVoid);
// "int"
- g_type_map.Append(ConstString("int").GetStringRef(), eBasicTypeInt);
- g_type_map.Append(ConstString("uint").GetStringRef(),
-eBasicTypeUnsignedInt);
+ g_type_map.Append(ConstString("int"), eBasicTypeInt);
+ g_type_map.Append(ConstString("uint"), eBasicTypeUnsignedInt);
// Miscellaneous
- g_type_map.Append(ConstString("bool").GetStringRef(), eBasicTypeBool);
+ g_type_map.Append(ConstString("bool"), eBasicTypeBool);
// Others. Should these map to C types?
- g_type_map.Append(ConstString("byte").GetStringRef(), eBasicTypeOther);
- g_type_map.Append(ConstString("uint8").GetStringRef(), eBasicTypeOther);
- g_type_map.Append(ConstString("uint16").GetStringRef(), eBasicTypeOther);
- g_type_map.Append(ConstString("uint32").GetStringRef(), eBasicTypeOther);
- g_type_map.Append(ConstString("uint64").GetStringRef(), eBasicTypeOther);
- g_type_map.Append(ConstString("int8").GetStringRef(), eBasicTypeOther);
- g_type_map.Append(ConstString("int16").GetStringRef(), eBasicTypeOther);
- g_type_map.Append(ConstString("int32").GetStringRef(), eBasicTypeOther);
- g_type_map.Append(ConstString("int64").GetStringRef(), eBasicTypeOther);
- g_type_map.Append(ConstString("float32").GetStringRef(), eBasicTypeOther);
- g_type_map.Append(ConstString("float64").GetStringRef(), eBasicTypeOther);
- g_type_map.Append(ConstString("uintptr").GetStringRef(), eBasicTypeOther);
+ g_type_map.Append(ConstString("byte"), eBasicTypeOther);
+ g_type_map.Append(ConstString("uint8"), eBasicTypeOther);
+ g_type_map.Append(ConstString("uint16"), eBasicTypeOther);
+ g_type_map.Append(ConstString("uint32"), eBasicTypeOther);
+ g_type_map.Append(ConstString("uint64"), eBasicTypeOther);
+ g_type_map.Append(ConstString("int8"), eBasicTypeOther);
+ g_type_map.Append(ConstString("int16"), eBasicTypeOther);
+ g_type_map.Append(ConstString("int32"), eBasicTypeOther);
+ g_type_map.Append(ConstString("int64"), eBasicTypeOther);
+ g_type_map.Append(ConstString("float32"), eBasicTypeOther);
+ g_type_map.Append(ConstString("float64"), eBasicTypeOther);
+ g_type_map.Append(ConstString("uintptr"), eBasicTypeOther);
g_type_map.Sort();
});
-return g_type_map.Find(name.GetStringRef(), eBasicTypeInvalid);
+return g_type_map.Find(name, eBasicTypeInvalid);
}
return eBasicTypeInvalid;
}
Index: lldb/trunk/source/Symbol/ClangASTContext.cpp
===
--- lldb/trunk/source/Symbol/ClangASTContext.cpp
+++ lldb/trunk/source/Symbol/ClangASTContext.cpp
@@ -954,75 +954,60 @@
static llvm::once_flag g_once_flag;
llvm::call_once(g_once_flag, []() {
// "void"
- g_type_map.Append(ConstString("void").GetStringRef(), eBasicTypeVoid);
+ g_type_map.Append(ConstString("void"), eBasicTypeVoid);
// "char"
- g_type_map.Append(ConstString("char").GetStringRef(), eBasicTypeChar);
- g_type_map.Append(ConstString("signed char").GetStringRef(),
-eBasicTypeSignedChar);
- g_type_map.Append(ConstString("unsigned char").GetStringRef(),
-eBasicTypeUnsignedChar);
- g_type_map.Append(ConstString("wchar_t").GetStringRef(), eBasicTypeWChar);
- g_type_map.Append(ConstString("signed wchar_t").GetStringRef(),
-
[Lldb-commits] [lldb] r301908 - Change UniqueCStringMap to use ConstString as the key
Author: labath
Date: Tue May 2 05:17:30 2017
New Revision: 301908
URL: http://llvm.org/viewvc/llvm-project?rev=301908&view=rev
Log:
Change UniqueCStringMap to use ConstString as the key
Summary:
UniqueCStringMap "sorts" the entries for fast lookup, but really it only cares
about uniqueness. ConstString can be compared by pointer alone, rather than
with strcmp, resulting in much faster comparisons. Change the interface to
take ConstString instead, and propagate use of the type to the callers where
appropriate.
Reviewers: #lldb, clayborg
Reviewed By: clayborg
Subscribers: labath, jasonmolenda, lldb-commits
Differential Revision: https://reviews.llvm.org/D32316
Patch by Scott Smith .
Modified:
lldb/trunk/include/lldb/Core/UniqueCStringMap.h
lldb/trunk/include/lldb/Symbol/ObjectFile.h
lldb/trunk/source/Interpreter/OptionValueEnumeration.cpp
lldb/trunk/source/Interpreter/OptionValueProperties.cpp
lldb/trunk/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.h
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/NameToDIE.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/NameToDIE.h
lldb/trunk/source/Symbol/ClangASTContext.cpp
lldb/trunk/source/Symbol/GoASTContext.cpp
lldb/trunk/source/Symbol/Symtab.cpp
Modified: lldb/trunk/include/lldb/Core/UniqueCStringMap.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/UniqueCStringMap.h?rev=301908&r1=301907&r2=301908&view=diff
==
--- lldb/trunk/include/lldb/Core/UniqueCStringMap.h (original)
+++ lldb/trunk/include/lldb/Core/UniqueCStringMap.h Tue May 2 05:17:30 2017
@@ -17,10 +17,9 @@
// Other libraries and framework includes
// Project includes
+#include "lldb/Utility/ConstString.h"
#include "lldb/Utility/RegularExpression.h"
-#include "llvm/ADT/StringRef.h"
-
namespace lldb_private {
//--
@@ -37,13 +36,17 @@ public:
struct Entry {
Entry() {}
-Entry(llvm::StringRef cstr) : cstring(cstr), value() {}
+Entry(ConstString cstr) : cstring(cstr), value() {}
-Entry(llvm::StringRef cstr, const T &v) : cstring(cstr), value(v) {}
+Entry(ConstString cstr, const T &v) : cstring(cstr), value(v) {}
-bool operator<(const Entry &rhs) const { return cstring < rhs.cstring; }
+// This is only for uniqueness, not lexicographical ordering, so we can
+// just compare pointers.
+bool operator<(const Entry &rhs) const {
+ return cstring.GetCString() < rhs.cstring.GetCString();
+}
-llvm::StringRef cstring;
+ConstString cstring;
T value;
};
@@ -52,7 +55,7 @@ public:
// this map, then later call UniqueCStringMap::Sort() before doing
// any searches by name.
//--
- void Append(llvm::StringRef unique_cstr, const T &value) {
+ void Append(ConstString unique_cstr, const T &value) {
m_map.push_back(typename UniqueCStringMap::Entry(unique_cstr, value));
}
@@ -64,7 +67,7 @@ public:
// Call this function to always keep the map sorted when putting
// entries into the map.
//--
- void Insert(llvm::StringRef unique_cstr, const T &value) {
+ void Insert(ConstString unique_cstr, const T &value) {
typename UniqueCStringMap::Entry e(unique_cstr, value);
m_map.insert(std::upper_bound(m_map.begin(), m_map.end(), e), e);
}
@@ -87,7 +90,7 @@ public:
return false;
}
- llvm::StringRef GetCStringAtIndexUnchecked(uint32_t idx) const {
+ ConstString GetCStringAtIndexUnchecked(uint32_t idx) const {
return m_map[idx].cstring;
}
@@ -101,8 +104,8 @@ public:
return m_map[idx].value;
}
- llvm::StringRef GetCStringAtIndex(uint32_t idx) const {
-return ((idx < m_map.size()) ? m_map[idx].cstring : llvm::StringRef());
+ ConstString GetCStringAtIndex(uint32_t idx) const {
+return ((idx < m_map.size()) ? m_map[idx].cstring : ConstString());
}
//--
@@ -113,7 +116,7 @@ public:
// T values and only if there is a sensible failure value that can
// be returned and that won't match any existing values.
//--
- T Find(llvm::StringRef unique_cstr, T fail_value) const {
+ T Find(ConstString unique_cstr, T fail_value) const {
Entry search_entry(unique_cstr);
const_iterator end = m_map.end();
const_iterator pos = std::lower_bound(m_map.begin(), end, search_entry);
@@ -131,15 +134,12 @@ public:
// The caller is responsible for ensuring that the collection does
// not ch
[Lldb-commits] [PATCH] D32168: [LLDB][MIPS] Fix TestStepOverBreakpoint.py failure
nitesh.jain updated this revision to Diff 97415.
nitesh.jain added a comment.
Update diff as per suggestion.
https://reviews.llvm.org/D32168
Files:
include/lldb/API/SBAddress.h
include/lldb/API/SBInstruction.h
include/lldb/API/SBInstructionList.h
include/lldb/Core/Disassembler.h
packages/Python/lldbsuite/test/functionalities/breakpoint/step_over_breakpoint/TestStepOverBreakpoint.py
scripts/interface/SBInstruction.i
scripts/interface/SBInstructionList.i
source/API/SBAddress.cpp
source/API/SBInstruction.cpp
source/API/SBInstructionList.cpp
source/Core/Disassembler.cpp
Index: source/Core/Disassembler.cpp
===
--- source/Core/Disassembler.cpp
+++ source/Core/Disassembler.cpp
@@ -759,6 +759,10 @@
return false;
}
+bool Instruction::CanSetBreakpoint () {
+ return !HasDelaySlot();
+}
+
bool Instruction::HasDelaySlot() {
// Default is false.
return false;
Index: source/API/SBInstructionList.cpp
===
--- source/API/SBInstructionList.cpp
+++ source/API/SBInstructionList.cpp
@@ -9,6 +9,7 @@
#include "lldb/API/SBInstructionList.h"
#include "lldb/API/SBInstruction.h"
+#include "lldb/API/SBAddress.h"
#include "lldb/API/SBStream.h"
#include "lldb/Core/Disassembler.h"
#include "lldb/Core/Module.h"
@@ -49,6 +50,31 @@
return inst;
}
+size_t SBInstructionList::GetInstructionsCount(const SBAddress &start,
+ const SBAddress &end,
+ bool canSetBreakpoint) {
+ size_t num_instructions = GetSize();
+ size_t i = 0;
+ SBAddress addr;
+ size_t lower_index = 0;
+ size_t upper_index = 0;
+ size_t instructions_to_skip = 0;
+ for (i = 0; i < num_instructions; ++i) {
+addr = GetInstructionAtIndex(i).GetAddress();
+if (start == addr)
+ lower_index = i;
+if (end == addr)
+ upper_index = i;
+ }
+ if (canSetBreakpoint)
+for (i = lower_index; i <= upper_index; ++i) {
+ SBInstruction insn = GetInstructionAtIndex(i);
+ if (!insn.CanSetBreakpoint())
+++instructions_to_skip;
+}
+ return upper_index - lower_index - instructions_to_skip;
+}
+
void SBInstructionList::Clear() { m_opaque_sp.reset(); }
void SBInstructionList::AppendInstruction(SBInstruction insn) {}
Index: source/API/SBInstruction.cpp
===
--- source/API/SBInstruction.cpp
+++ source/API/SBInstruction.cpp
@@ -176,6 +176,13 @@
return false;
}
+bool SBInstruction::CanSetBreakpoint () {
+ lldb::InstructionSP inst_sp(GetOpaque());
+ if (inst_sp)
+return inst_sp->CanSetBreakpoint();
+ return false;
+}
+
lldb::InstructionSP SBInstruction::GetOpaque() {
if (m_opaque_sp)
return m_opaque_sp->GetSP();
Index: source/API/SBAddress.cpp
===
--- source/API/SBAddress.cpp
+++ source/API/SBAddress.cpp
@@ -55,6 +55,12 @@
return *this;
}
+bool lldb::operator==(const SBAddress &lhs, const SBAddress &rhs) {
+ if (lhs.IsValid() && rhs.IsValid())
+return lhs.ref() == rhs.ref();
+ return false;
+}
+
bool SBAddress::IsValid() const {
return m_opaque_ap.get() != NULL && m_opaque_ap->IsValid();
}
Index: scripts/interface/SBInstructionList.i
===
--- scripts/interface/SBInstructionList.i
+++ scripts/interface/SBInstructionList.i
@@ -44,6 +44,9 @@
lldb::SBInstruction
GetInstructionAtIndex (uint32_t idx);
+size_t GetInstructionsCount(const SBAddress &start, const SBAddress &end,
+bool canSetBreakpoint);
+
void
Clear ();
Index: scripts/interface/SBInstruction.i
===
--- scripts/interface/SBInstruction.i
+++ scripts/interface/SBInstruction.i
@@ -54,6 +54,9 @@
bool
HasDelaySlot ();
+bool
+CanSetBreakpoint ();
+
void
Print (FILE *out);
Index: packages/Python/lldbsuite/test/functionalities/breakpoint/step_over_breakpoint/TestStepOverBreakpoint.py
===
--- packages/Python/lldbsuite/test/functionalities/breakpoint/step_over_breakpoint/TestStepOverBreakpoint.py
+++ packages/Python/lldbsuite/test/functionalities/breakpoint/step_over_breakpoint/TestStepOverBreakpoint.py
@@ -62,19 +62,11 @@
instructions = function.GetInstructions(self.target)
addr_1 = self.breakpoint1.GetLocationAtIndex(0).GetAddress()
addr_4 = self.breakpoint4.GetLocationAtIndex(0).GetAddress()
-delay_slot = 0
-addr_1_load_address = addr_1.GetLoadAddress(self.target)
-addr_4_load_address = addr_4.GetLoadAddress(self.target)
-for i in range(instructions.GetSize()) :
-addr = instructions.GetInstructionAtIndex(i).GetAddress()
-
[Lldb-commits] [PATCH] D32708: Check for lack of C++ context first when demangling
labath added a comment. I am having trouble applying this. Do you need to rebase or something? Repository: rL LLVM https://reviews.llvm.org/D32708 ___ 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
labath added subscribers: jingham, labath. labath added a comment. Thanks for the patch. Could you also write a test case for the bug? It sounds like all that is necessary is to move the commands from your commit message into a test. Jim, who would be a good reviewer for this? 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] D32503: Remove unused code related to CPlusPlusLanguage::FindEquivalentNames
This revision was automatically updated to reflect the committed changes.
Closed by commit rL301903: Remove unused code related to
CPlusPlusLanguage::FindEquivalentNames (authored by labath).
Changed prior to commit:
https://reviews.llvm.org/D32503?vs=96623&id=97408#toc
Repository:
rL LLVM
https://reviews.llvm.org/D32503
Files:
lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.h
Index: lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.h
===
--- lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.h
+++ lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.h
@@ -119,18 +119,6 @@
llvm::StringRef &context,
llvm::StringRef &identifier);
- // in some cases, compilers will output different names for one same type.
- // when that happens, it might be impossible
- // to construct SBType objects for a valid type, because the name that is
- // available is not the same as the name that
- // can be used as a search key in FindTypes(). the equivalents map here is
- // meant to return possible alternative names
- // for a type through which a search can be conducted. Currently, this is only
- // enabled for C++ but can be extended
- // to ObjC or other languages if necessary
- static uint32_t FindEquivalentNames(ConstString type_name,
- std::vector &equivalents);
-
// Given a mangled function name, calculates some alternative manglings since
// the compiler mangling may not line up with the symbol we are expecting
static uint32_t
Index: lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
===
--- lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
+++ lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
@@ -271,144 +271,6 @@
return false;
}
-class CPPRuntimeEquivalents {
-public:
- CPPRuntimeEquivalents() {
-m_impl.Append(ConstString("std::basic_string, "
- "std::allocator >")
- .GetStringRef(),
- ConstString("basic_string"));
-
-// these two (with a prefixed std::) occur when c++stdlib string class
-// occurs as a template argument in some STL container
-m_impl.Append(ConstString("std::basic_string, "
- "std::allocator >")
- .GetStringRef(),
- ConstString("std::basic_string"));
-
-m_impl.Sort();
- }
-
- void Add(ConstString &type_name, ConstString &type_equivalent) {
-m_impl.Insert(type_name.GetStringRef(), type_equivalent);
- }
-
- uint32_t FindExactMatches(ConstString &type_name,
-std::vector &equivalents) {
-uint32_t count = 0;
-
-for (ImplData match =
- m_impl.FindFirstValueForName(type_name.GetStringRef());
- match != nullptr; match = m_impl.FindNextValueForName(match)) {
- equivalents.push_back(match->value);
- count++;
-}
-
-return count;
- }
-
- // partial matches can occur when a name with equivalents is a template
- // argument.
- // e.g. we may have "class Foo" be a match for "struct Bar". if we have a
- // typename
- // such as "class Templatized" we want this to be
- // replaced with
- // "class Templatized". Since partial matching is time
- // consuming
- // once we get a partial match, we add it to the exact matches list for faster
- // retrieval
- uint32_t FindPartialMatches(ConstString &type_name,
- std::vector &equivalents) {
-uint32_t count = 0;
-
-llvm::StringRef type_name_cstr = type_name.GetStringRef();
-
-size_t items_count = m_impl.GetSize();
-
-for (size_t item = 0; item < items_count; item++) {
- llvm::StringRef key_cstr = m_impl.GetCStringAtIndex(item);
- if (type_name_cstr.contains(key_cstr)) {
-count += AppendReplacements(type_name_cstr, key_cstr, equivalents);
- }
-}
-
-return count;
- }
-
-private:
- std::string &replace(std::string &target, std::string &pattern,
- std::string &with) {
-size_t pos;
-size_t pattern_len = pattern.size();
-
-while ((pos = target.find(pattern)) != std::string::npos)
- target.replace(pos, pattern_len, with);
-
-return target;
- }
-
- uint32_t AppendReplacements(llvm::StringRef original,
- llvm::StringRef matching_key,
- std::vector &equivalents) {
-std::string matching_key_str(matching_key);
-ConstString original_const(original);
-
-uint32_t count = 0;
-
-for (ImplData match = m_impl.FindFirstValueForName(matching_key);
- match != nullptr; match = m_impl.FindNextValueForName(
[Lldb-commits] [lldb] r301903 - Remove unused code related to CPlusPlusLanguage::FindEquivalentNames
Author: labath
Date: Tue May 2 04:00:52 2017
New Revision: 301903
URL: http://llvm.org/viewvc/llvm-project?rev=301903&view=rev
Log:
Remove unused code related to CPlusPlusLanguage::FindEquivalentNames
Summary: It is simply unused, and the header for it is private, so there should
be no external dependencies.
Reviewers: #lldb, zturner
Reviewed By: zturner
Subscribers: zturner, tberghammer, jingham, lldb-commits
Differential Revision: https://reviews.llvm.org/D32503
Patch by Scott Smith .
Modified:
lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.h
Modified: lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp?rev=301903&r1=301902&r2=301903&view=diff
==
--- lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
(original)
+++ lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp Tue May
2 04:00:52 2017
@@ -271,144 +271,6 @@ bool CPlusPlusLanguage::ExtractContextAn
return false;
}
-class CPPRuntimeEquivalents {
-public:
- CPPRuntimeEquivalents() {
-m_impl.Append(ConstString("std::basic_string,
"
- "std::allocator >")
- .GetStringRef(),
- ConstString("basic_string"));
-
-// these two (with a prefixed std::) occur when c++stdlib string class
-// occurs as a template argument in some STL container
-m_impl.Append(ConstString("std::basic_string,
"
- "std::allocator >")
- .GetStringRef(),
- ConstString("std::basic_string"));
-
-m_impl.Sort();
- }
-
- void Add(ConstString &type_name, ConstString &type_equivalent) {
-m_impl.Insert(type_name.GetStringRef(), type_equivalent);
- }
-
- uint32_t FindExactMatches(ConstString &type_name,
-std::vector &equivalents) {
-uint32_t count = 0;
-
-for (ImplData match =
- m_impl.FindFirstValueForName(type_name.GetStringRef());
- match != nullptr; match = m_impl.FindNextValueForName(match)) {
- equivalents.push_back(match->value);
- count++;
-}
-
-return count;
- }
-
- // partial matches can occur when a name with equivalents is a template
- // argument.
- // e.g. we may have "class Foo" be a match for "struct Bar". if we have a
- // typename
- // such as "class Templatized" we want this to be
- // replaced with
- // "class Templatized". Since partial matching is time
- // consuming
- // once we get a partial match, we add it to the exact matches list for
faster
- // retrieval
- uint32_t FindPartialMatches(ConstString &type_name,
- std::vector &equivalents) {
-uint32_t count = 0;
-
-llvm::StringRef type_name_cstr = type_name.GetStringRef();
-
-size_t items_count = m_impl.GetSize();
-
-for (size_t item = 0; item < items_count; item++) {
- llvm::StringRef key_cstr = m_impl.GetCStringAtIndex(item);
- if (type_name_cstr.contains(key_cstr)) {
-count += AppendReplacements(type_name_cstr, key_cstr, equivalents);
- }
-}
-
-return count;
- }
-
-private:
- std::string &replace(std::string &target, std::string &pattern,
- std::string &with) {
-size_t pos;
-size_t pattern_len = pattern.size();
-
-while ((pos = target.find(pattern)) != std::string::npos)
- target.replace(pos, pattern_len, with);
-
-return target;
- }
-
- uint32_t AppendReplacements(llvm::StringRef original,
- llvm::StringRef matching_key,
- std::vector &equivalents) {
-std::string matching_key_str(matching_key);
-ConstString original_const(original);
-
-uint32_t count = 0;
-
-for (ImplData match = m_impl.FindFirstValueForName(matching_key);
- match != nullptr; match = m_impl.FindNextValueForName(match)) {
- std::string target(original);
- std::string equiv_class(match->value.AsCString());
-
- replace(target, matching_key_str, equiv_class);
-
- ConstString target_const(target.c_str());
-
-// you will most probably want to leave this off since it might make this map
-// grow indefinitely
-#ifdef ENABLE_CPP_EQUIVALENTS_MAP_TO_GROW
- Add(original_const, target_const);
-#endif
- equivalents.push_back(target_const);
-
- count++;
-}
-
-return count;
- }
-
- typedef UniqueCStringMap Impl;
- typedef const Impl::Entry *ImplData;
- Impl m_impl;
-};
-
-static CPPRuntimeEquivalents &GetEquivalentsMap() {
- static CPPRuntimeEquivalents g_equivalents_map;
- return g_equivalents_map;
-}
-
-uint32_t
-CPlusPlusLanguage::FindEquivalentNames(ConstString type_name,
- std::vector &equivalents
[Lldb-commits] [PATCH] D32719: Don't attempt to use mpx registers on unsupported platforms
labath added a comment. Couldn't we just update the cpp file to do #ifndef PR_MPX_ENABLE_MANAGEMENT return -1; #endif ? https://reviews.llvm.org/D32719 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
