Re: [lldb-dev] Parallelizing loading of shared libraries

[Pavel Labath via lldb-dev]

On 1 May 2017 at 22:58, Scott Smith  wrote:
> On Mon, May 1, 2017 at 2:42 PM, Pavel Labath  wrote:
>>
>> Besides, hardcoding the nesting logic into "add" is kinda wrong.
>> Adding a task is not the problematic operation, waiting for the result
>> of one is. Granted, generally these happen on the same thread, but
>> they don't have to be -- you can write a continuation-style
>> computation, where you do a bit of work, and then enqueue a task to do
>> the rest. This would create an infinite pool depth here.
>
>
> True, but that doesn't seem to be the style of code here.  If it were you
> wouldn't need multiple pools, since you'd just wait for the callback that
> your work was done.
>
>>
>>
>> Btw, are we sure it's not possible to solve this with just one thread
>> pool. What would happen if we changed the implementation of "wait" so
>> that if the target task is not scheduled yet, we just go ahead an
>> compute it on our thread? I haven't thought through all the details,
>> but is sounds like this could actually give better performance in some
>> scenarios...
>
>
> My initial reaction was "that wouldn't work, what if you ran another posix
> dl load?"  But then I suppose *it* would run more work, and eventually you'd
> run a leaf task and finish something.
>
> You'd have to make sure your work could be run regardless of what mutexes
> the caller already had (since you may be running work for another
> subsystem), but that's probably not too onerous, esp given how many
> recursive mutexes lldb uses..

Is it any worse that if the thread got stuck in the "wait" call? Even
with a dead-lock-free thread pool the task at hand still would not be
able to make progress, as the waiter  would hold the mutex even while
blocked (and recursiveness will not save you here).

>
> I think that's all the more reason we *should* work on getting something into 
> LLVM first.  Anything we already have in LLDB, or any modifications we make 
> will likely not be pushed up to LLVM, especially since LLVM already has a 
> ThreadPool, so any changes you make to LLDB's thread pool will likely have to 
> be re-written when trying to get it to LLVM.  And since, as you said, more 
> projects depend on LLVM than LLDB, there's a good chance that the baseline 
> you'd be starting from when making improvements is more easily adaptable to 
> what you want to do.  LLDB has a long history of being shy of making changes 
> in LLVM where appropriate, and myself and others have started pushing back on 
> that more and more, because it accumulates long term technical debt.
> In my experience, "let's just get it into LLDB first and then work on getting 
> it up to LLVM later" ends up being "well, it's in LLDB now, so since my 
> immediate problem is solved I may or may not have time to revisit this in the 
> future"  (even if the original intent is sincere).
> If there is some resistance getting changes into LLVM, feel free to add me as 
> a reviewer, and I can find the right people to move it along.  I'd still like 
> to at least hear a strong argument for why the existing implementation in 
> LLVM is unacceptable for what we need.  I'm ok with "non optimal".  Unless 
> it's "unsuitable", we should start there and make incremental improvements.

I think we could solve our current problem by just having two global
instances of llvm::ThreadPool. The only issue I have with that is that
I will then have 100 threads around constantly, which will make
debugging lldb harder (although even that can be viewed as an
incentive to make debugging threaded programs easier :) ).

The reason I am not overly supportive of doing the design in llvm is
that I think we are trying to come up with a solution that will work
around issues with the lldb design, and I am not sure if that's the
right motivation. I am not against that either, though...
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] New build machine in the cluster lldb-amd64-ninja-netbsd8

[Pavel Labath via lldb-dev]

On 29 April 2017 at 12:25, Kamil Rytarowski  wrote:
> I've managed to configure lldb-amd64-ninja-netbsd7 to run the unit
> tests. There has been observed a regression as the number of passing
> ones dropped recently from 600+/1200+ to 200+. I've reproduced this also
> locally.
>
> http://lab.llvm.org:8014/builders/lldb-amd64-ninja-netbsd7/builds/75
>
> I'm still using google scripts. I think we should drop "upload test
> traces" on !Google platforms.
Yes, those classes need de-googlyfying. If you're going to touch them,
you can also delete the "update NDK" step totally -- it was a bad
idea, and we're not using it.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Unable to build LLDB 4.0 on Debian Linux

[Pavel Labath via lldb-dev]

What's the cmake command you are using?

It sounds like you somehow ended up enabling -Werror, which is
confusing the backtrace-detection code (and probably most of the other
cmake compile checks).

One of the workarounds would be to disable -Werror.

pl

On 28 April 2017 at 22:36, Andy Gibbs via lldb-dev
 wrote:
> Hi,
>
>
> I am having a problem building the 4.0 release branch of LLDB on Debian
> Stretch.  Cmake returns the following fault:
>
>
>   -- LLDB version: 4.0.0
>   -- Found LibXml2: /usr/lib/x86_64-linux-gnu/libxml2.so (found version
> "2.9.4")
>   -- Performing Test HAVE_PROCESS_VM_READV
>   -- Performing Test HAVE_PROCESS_VM_READV - Success
>   -- Found Curses: /usr/lib/x86_64-linux-gnu/libcurses.so
>   -- Looking for __GLIBCXX__
>   -- Looking for __GLIBCXX__ - found
>   -- Performing Test LLDB_USING_LIBSTDCXX_4_9
>   -- Performing Test LLDB_USING_LIBSTDCXX_4_9 - Success
>   -- Looking for backtrace
>   -- Looking for backtrace - not found
>   -- Could NOT find Backtrace (missing:  Backtrace_LIBRARY)
>   -- Found Doxygen: /usr/bin/doxygen (found version "1.8.13")
>   -- Found SWIG: /usr/bin/swig3.0 (found version "3.0.10")
>   -- Performing Test CXX_SUPPORTS_NO_MACRO_REDEFINED
>   -- Performing Test CXX_SUPPORTS_NO_MACRO_REDEFINED - Success
>   -- Symbols (liblldb): exporting all symbols from the lldb namespace
>   CMake Error: The following variables are used in this project, but they
> are set to NOTFOUND.
>   Please set them or make sure they are set and tested correctly in the
> CMake files:
>   Backtrace_LIBRARY (ADVANCED)
>   linked by target "liblldb" in directory
> clang-4.0/tools/lldb/source/API
>   linked by target "LLDBBreakpointTests" in directory
> clang-4.0/tools/lldb/unittests/Breakpoint
>   linked by target "LLDBCoreTests" in directory
> clang-4.0/tools/lldb/unittests/Core
>   linked by target "EditlineTests" in directory
> clang-4.0/tools/lldb/unittests/Editline
>   linked by target "ExpressionTests" in directory
> clang-4.0/tools/lldb/unittests/Expression
>   linked by target "HostTests" in directory
> clang-4.0/tools/lldb/unittests/Host
>   linked by target "InterpreterTests" in directory
> clang-4.0/tools/lldb/unittests/Interpreter
>   linked by target "LanguageCPlusPlusTests" in directory
> clang-4.0/tools/lldb/unittests/Language/CPlusPlus
>   linked by target "LLDBPlatformTests" in directory
> clang-4.0/tools/lldb/unittests/Platform
>   linked by target "ProcessGdbRemoteTests" in directory
> clang-4.0/tools/lldb/unittests/Process/gdb-remote
>   linked by target "LLDBMinidumpTests" in directory
> clang-4.0/tools/lldb/unittests/Process/minidump
>   linked by target "ScriptInterpreterPythonTests" in directory
> clang-4.0/tools/lldb/unittests/ScriptInterpreter/Python
>   linked by target "SymbolTests" in directory
> clang-4.0/tools/lldb/unittests/Symbol
>   linked by target "SymbolFileDWARFTests" in directory
> clang-4.0/tools/lldb/unittests/SymbolFile/DWARF
>   linked by target "UnwindAssemblyx86Tests" in directory
> clang-4.0/tools/lldb/unittests/UnwindAssembly/x86
>   linked by target "UtilityTests" in directory
> clang-4.0/tools/lldb/unittests/Utility
>
>   -- Configuring incomplete, errors occurred!
>   See also "build-4.0/bootstrap/CMakeFiles/CMakeOutput.log".
>   See also "build-4.0/bootstrap/CMakeFiles/CMakeError.log".
>
>
>
> The output from CMakeError.log is:
>
>
>   Determining if the backtrace exist failed with the following output:
>   Change Dir: build-4.0/bootstrap/CMakeFiles/CMakeTmp
>
>   Run Build Command:"build-4.0/bin/ninja" "cmTC_1e735"
>   [1/2] Building C object CMakeFiles/cmTC_1e735.dir/CheckSymbolExists.c.o
>   FAILED: CMakeFiles/cmTC_1e735.dir/CheckSymbolExists.c.o
>   /usr/bin/cc-fPIC -Wall -W -Wno-unused-parameter -Wwrite-strings
> -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-comment
> -Werror -Werror=date-time -ffunction-sections -fdata-sections -o
> CMakeFiles/cmTC_1e735.dir/CheckSymbolExists.c.o   -c
> build-4.0/bootstrap/CMakeFiles/CMakeTmp/CheckSymbolExists.c
>   build-4.0/bootstrap/CMakeFiles/CMakeTmp/CheckSymbolExists.c: In function
> ‘main’:
>   build-4.0/bootstrap/CMakeFiles/CMakeTmp/CheckSymbolExists.c:8:11: error:
> ISO C forbids conversion of function pointer to object pointer type
> [-Werror=pedantic]
>  return ((int*)(&backtrace))[argc];
>  ^
>   cc1: all warnings being treated as errors
>   ninja: build stopped: subcommand failed.
>
>   File build-4.0/bootstrap/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
>   /* */
>   #include 
>
>   int main(int argc, char** argv)
>   {
> (void)argv;
>   #ifndef backtrace
> return ((int*)(&backtrace))[argc];
>   #else
> (void)argc;
> return 0;
>   #endif
>   }
>
>
> It seems that the detection routine is invalid.  The gcc in use is 6.3.0.
> Anyone any idea how to fix / work around this problem?
>
>
> Many thanks,
>
>
> Andy
>
>
>
>
>
>
> ___
>

Re: [lldb-dev] Parallelizing loading of shared libraries

[Zachary Turner via lldb-dev]

Fwiw I haven't even followed the discussion closely enough to know what the
issues with the lldb task runner even are.

My motivation is simple though: don't reinvent the wheel.

Iirc LLDB task runner was added before llvm's thread pool existed (I
haven't checked, so i may be wrong about this). If that's the case, I would
just assume replace all existing users of lldb task runner with llvm's as
well and delete lldb's

Regarding the issue with making debugging harder, llvm has functions to set
thread name now. We could name all threadpool threads
On Tue, May 2, 2017 at 3:05 AM Pavel Labath via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> On 1 May 2017 at 22:58, Scott Smith  wrote:
> > On Mon, May 1, 2017 at 2:42 PM, Pavel Labath  wrote:
> >>
> >> Besides, hardcoding the nesting logic into "add" is kinda wrong.
> >> Adding a task is not the problematic operation, waiting for the result
> >> of one is. Granted, generally these happen on the same thread, but
> >> they don't have to be -- you can write a continuation-style
> >> computation, where you do a bit of work, and then enqueue a task to do
> >> the rest. This would create an infinite pool depth here.
> >
> >
> > True, but that doesn't seem to be the style of code here.  If it were you
> > wouldn't need multiple pools, since you'd just wait for the callback that
> > your work was done.
> >
> >>
> >>
> >> Btw, are we sure it's not possible to solve this with just one thread
> >> pool. What would happen if we changed the implementation of "wait" so
> >> that if the target task is not scheduled yet, we just go ahead an
> >> compute it on our thread? I haven't thought through all the details,
> >> but is sounds like this could actually give better performance in some
> >> scenarios...
> >
> >
> > My initial reaction was "that wouldn't work, what if you ran another
> posix
> > dl load?"  But then I suppose *it* would run more work, and eventually
> you'd
> > run a leaf task and finish something.
> >
> > You'd have to make sure your work could be run regardless of what mutexes
> > the caller already had (since you may be running work for another
> > subsystem), but that's probably not too onerous, esp given how many
> > recursive mutexes lldb uses..
>
> Is it any worse that if the thread got stuck in the "wait" call? Even
> with a dead-lock-free thread pool the task at hand still would not be
> able to make progress, as the waiter  would hold the mutex even while
> blocked (and recursiveness will not save you here).
>
> >
> > I think that's all the more reason we *should* work on getting something
> into LLVM first.  Anything we already have in LLDB, or any modifications we
> make will likely not be pushed up to LLVM, especially since LLVM already
> has a ThreadPool, so any changes you make to LLDB's thread pool will likely
> have to be re-written when trying to get it to LLVM.  And since, as you
> said, more projects depend on LLVM than LLDB, there's a good chance that
> the baseline you'd be starting from when making improvements is more easily
> adaptable to what you want to do.  LLDB has a long history of being shy of
> making changes in LLVM where appropriate, and myself and others have
> started pushing back on that more and more, because it accumulates long
> term technical debt.
> > In my experience, "let's just get it into LLDB first and then work on
> getting it up to LLVM later" ends up being "well, it's in LLDB now, so
> since my immediate problem is solved I may or may not have time to revisit
> this in the future"  (even if the original intent is sincere).
> > If there is some resistance getting changes into LLVM, feel free to add
> me as a reviewer, and I can find the right people to move it along.  I'd
> still like to at least hear a strong argument for why the existing
> implementation in LLVM is unacceptable for what we need.  I'm ok with "non
> optimal".  Unless it's "unsuitable", we should start there and make
> incremental improvements.
>
> I think we could solve our current problem by just having two global
> instances of llvm::ThreadPool. The only issue I have with that is that
> I will then have 100 threads around constantly, which will make
> debugging lldb harder (although even that can be viewed as an
> incentive to make debugging threaded programs easier :) ).
>
> The reason I am not overly supportive of doing the design in llvm is
> that I think we are trying to come up with a solution that will work
> around issues with the lldb design, and I am not sure if that's the
> right motivation. I am not against that either, though...
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Unable to build LLDB 4.0 on Debian Linux

[Zachary Turner via lldb-dev]

This is in cmake detection code though, the options you set for your build
have no bearing there right?

This looks like a bug in cmake to me, perhaps a newer cmake version can fix
it?
On Tue, May 2, 2017 at 3:24 AM Pavel Labath via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> What's the cmake command you are using?
>
> It sounds like you somehow ended up enabling -Werror, which is
> confusing the backtrace-detection code (and probably most of the other
> cmake compile checks).
>
> One of the workarounds would be to disable -Werror.
>
> pl
>
> On 28 April 2017 at 22:36, Andy Gibbs via lldb-dev
>  wrote:
> > Hi,
> >
> >
> > I am having a problem building the 4.0 release branch of LLDB on Debian
> > Stretch.  Cmake returns the following fault:
> >
> >
> >   -- LLDB version: 4.0.0
> >   -- Found LibXml2: /usr/lib/x86_64-linux-gnu/libxml2.so (found version
> > "2.9.4")
> >   -- Performing Test HAVE_PROCESS_VM_READV
> >   -- Performing Test HAVE_PROCESS_VM_READV - Success
> >   -- Found Curses: /usr/lib/x86_64-linux-gnu/libcurses.so
> >   -- Looking for __GLIBCXX__
> >   -- Looking for __GLIBCXX__ - found
> >   -- Performing Test LLDB_USING_LIBSTDCXX_4_9
> >   -- Performing Test LLDB_USING_LIBSTDCXX_4_9 - Success
> >   -- Looking for backtrace
> >   -- Looking for backtrace - not found
> >   -- Could NOT find Backtrace (missing:  Backtrace_LIBRARY)
> >   -- Found Doxygen: /usr/bin/doxygen (found version "1.8.13")
> >   -- Found SWIG: /usr/bin/swig3.0 (found version "3.0.10")
> >   -- Performing Test CXX_SUPPORTS_NO_MACRO_REDEFINED
> >   -- Performing Test CXX_SUPPORTS_NO_MACRO_REDEFINED - Success
> >   -- Symbols (liblldb): exporting all symbols from the lldb namespace
> >   CMake Error: The following variables are used in this project, but they
> > are set to NOTFOUND.
> >   Please set them or make sure they are set and tested correctly in the
> > CMake files:
> >   Backtrace_LIBRARY (ADVANCED)
> >   linked by target "liblldb" in directory
> > clang-4.0/tools/lldb/source/API
> >   linked by target "LLDBBreakpointTests" in directory
> > clang-4.0/tools/lldb/unittests/Breakpoint
> >   linked by target "LLDBCoreTests" in directory
> > clang-4.0/tools/lldb/unittests/Core
> >   linked by target "EditlineTests" in directory
> > clang-4.0/tools/lldb/unittests/Editline
> >   linked by target "ExpressionTests" in directory
> > clang-4.0/tools/lldb/unittests/Expression
> >   linked by target "HostTests" in directory
> > clang-4.0/tools/lldb/unittests/Host
> >   linked by target "InterpreterTests" in directory
> > clang-4.0/tools/lldb/unittests/Interpreter
> >   linked by target "LanguageCPlusPlusTests" in directory
> > clang-4.0/tools/lldb/unittests/Language/CPlusPlus
> >   linked by target "LLDBPlatformTests" in directory
> > clang-4.0/tools/lldb/unittests/Platform
> >   linked by target "ProcessGdbRemoteTests" in directory
> > clang-4.0/tools/lldb/unittests/Process/gdb-remote
> >   linked by target "LLDBMinidumpTests" in directory
> > clang-4.0/tools/lldb/unittests/Process/minidump
> >   linked by target "ScriptInterpreterPythonTests" in directory
> > clang-4.0/tools/lldb/unittests/ScriptInterpreter/Python
> >   linked by target "SymbolTests" in directory
> > clang-4.0/tools/lldb/unittests/Symbol
> >   linked by target "SymbolFileDWARFTests" in directory
> > clang-4.0/tools/lldb/unittests/SymbolFile/DWARF
> >   linked by target "UnwindAssemblyx86Tests" in directory
> > clang-4.0/tools/lldb/unittests/UnwindAssembly/x86
> >   linked by target "UtilityTests" in directory
> > clang-4.0/tools/lldb/unittests/Utility
> >
> >   -- Configuring incomplete, errors occurred!
> >   See also "build-4.0/bootstrap/CMakeFiles/CMakeOutput.log".
> >   See also "build-4.0/bootstrap/CMakeFiles/CMakeError.log".
> >
> >
> >
> > The output from CMakeError.log is:
> >
> >
> >   Determining if the backtrace exist failed with the following output:
> >   Change Dir: build-4.0/bootstrap/CMakeFiles/CMakeTmp
> >
> >   Run Build Command:"build-4.0/bin/ninja" "cmTC_1e735"
> >   [1/2] Building C object CMakeFiles/cmTC_1e735.dir/CheckSymbolExists.c.o
> >   FAILED: CMakeFiles/cmTC_1e735.dir/CheckSymbolExists.c.o
> >   /usr/bin/cc-fPIC -Wall -W -Wno-unused-parameter -Wwrite-strings
> > -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-comment
> > -Werror -Werror=date-time -ffunction-sections -fdata-sections -o
> > CMakeFiles/cmTC_1e735.dir/CheckSymbolExists.c.o   -c
> > build-4.0/bootstrap/CMakeFiles/CMakeTmp/CheckSymbolExists.c
> >   build-4.0/bootstrap/CMakeFiles/CMakeTmp/CheckSymbolExists.c: In
> function
> > ‘main’:
> >   build-4.0/bootstrap/CMakeFiles/CMakeTmp/CheckSymbolExists.c:8:11:
> error:
> > ISO C forbids conversion of function pointer to object pointer type
> > [-Werror=pedantic]
> >  return ((int*)(&backtrace))[argc];
> >  ^
> >   cc1: all warnings being treated as errors
> >   ninja: build stopped: subcommand failed.
> >
> >   File build-4.0/bo

Re: [lldb-dev] NetBSD core(5) files for LLDB's test-suite

[Pavel Labath via lldb-dev]

Sorry it took me so long. I think it's fine to check a couple of those
in. When zipped, they will still be orders of magnitude smaller then
the windows minidump exe we are carrying around.

For the long term though, I'd like to add the necessary support to
llvm's obj2yaml to be able to generate these. As far as I can tell, it
just needs program header support added. Then we will be able to
generate truly small unit tests (e.g. by removing all the memory
segments for tests that only need threads signal or registers and
such).

pl

On 22 April 2017 at 01:59, Kamil Rytarowski  wrote:
> Hello,
>
> I've prepared two sets of core(5) files with the following programs:
>  - 1lwp_SIGSEGV (signal SIGSEGV emitted for thread)
>  - 1lwp_busyloop (signal SIGABRT emitted for the whole process)
>
> My compiler is GCC 5.4.0 and host NetBSD/amd64 7.99.70.
>
> The first set is written with a custom startup assembly without usage of
> libc. I used -nostdlib option for the compiler. The second set is plain
> C implementation.
>
> The first set generates files of size 6752 bytes/core. After compressing
> with the default options of bzip2, the size is respectively 1035 and 990
> bytes.
>
> The second set in C with regular system libraries gives core(5) files of
> size 103488 and 103472 bytes. bzip2 with the default options reduces
> their size to 15212 and 15040 bytes.
>
>
> Writing bare code starting additional LWP in the first approach is more
> difficult, especially since it will need to be ported to more platforms.
> I decided to implement just the libc version and go for native lwp
> interfaces and without usage of libpthread.
>
> The size of core(5) files is as follows: 131800 and 131784 bytes.
> Compressed with the default options of bzip2: 16345 and 16243 bytes.
>
>
> I propose to go for regular libc code version and optionally compress
> the binary files. I request to include Makefile and source code of files
> to LLDB. I propose to ship 4 core files per supported target architecture.
>
>
> I put the source code and NetBSD/amd64 core(5) files ready to pick-up here:
> http://www.netbsd.org/~kamil/lldb/netbsd-core/
>
>
> For the reference, I include the used source code below:
>
> Source C code:
> $ cat 1lwp_SIGSEGV.c
> void main(void)
> {
> volatile int *a = 0;
> *a = 100;
> }
> $ cat 1lwp_busyloop.c
> int main(int argc, char **argv)
> {
> for(;;)
> continue;
> }
>
>
> Startup assembly (there is replaced @VERSION@ with __NetBSD_Version__
> from /usr/include/sys/param.h):
> .globl _start
>
> .section ".note.netbsd.ident", "a", @note
> .long 2f-1f
> .long 4f-3f
> .long 1
> 1:  .asciz "NetBSD"
> 2:  .p2align 2
> 3:  .long @VERSION@
> 4:  .p2align 2
>
> .section .text
> _start:
> andq $0xfff0, %rsp
> subq $0x8, %rsp
> call main
>
>
>
> Source code with two LWPs (without libpthread):
> #include 
> #include 
> #include 
>
> static void
> lwp_main_func(void *arg)
> {
> #if 1
> volatile int *a = 0;
> *a = 100;
> #else
> for(;;)
> continue;
> #endif
> }
>
> int
> main(int argc, char **argv)
> {
> ucontext_t uc;
> lwpid_t lid;
> static const size_t ssize = 16*1024;
> void *stack;
>
> stack = malloc(ssize);
I wonder if this thing would be smaller if you put the stack in the
bss section (then you could avoid pulling malloc in, potentially).

> _lwp_makecontext(&uc, lwp_main_func, NULL, NULL, stack, ssize);
> _lwp_create(&uc, 0, &lid);
> _lwp_wait(lid, NULL);
> }
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Lack of parallelism

[Scott Smith via lldb-dev]

I've been trying to improve the parallelism of lldb but have run into an
odd roadblock.  I have the code at the point where it creates 40 worker
threads, and it stays that way because it has enough work to do.  However,
running 'top -d 1' shows that for the time in question, cpu load never gets
above 4-8 cpus (even though I have 40).

1. I tried mutrace, which measures mutex contention (I had to call
unsetenv("LD_PRELOAD") in main() so it wouldn't propagate to the process
being tested).  It indicated some minor contention, but not enough to be
the problem.  Regardless, I converted everything I could to lockfree
structures (TaskPool and ConstString) and it didn't help.

2. I tried strace, but I don't think strace can figure out how to trace
lldb.  It says it waits on a single futex for 8 seconds, and then is done.

I'm about to try lttng to trace all syscalls, but I was wondering if anyone
else had any ideas?  At one point I wondered if it was mmap kernel
semaphore contention, but that shouldn't affect faulting individual pages,
and I assume lldb doesn't call mmap all the time.

I'm getting a bit frustrated because lldb should be taking 1-2 seconds to
start up (it has ~45s of user+system work to do), but instead is taking
8-10, and I've been stuck there for a while.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Lack of parallelism

[Zachary Turner via lldb-dev]

If you have access to a Windows machine and you can reproduce the slowdown
there, there are surprisingly good tools available for diagnosing
parallelism and thread contention.

https://github.com/google/UIforETW

On Tue, May 2, 2017 at 8:09 AM Scott Smith via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I've been trying to improve the parallelism of lldb but have run into an
> odd roadblock.  I have the code at the point where it creates 40 worker
> threads, and it stays that way because it has enough work to do.  However,
> running 'top -d 1' shows that for the time in question, cpu load never gets
> above 4-8 cpus (even though I have 40).
>
> 1. I tried mutrace, which measures mutex contention (I had to call
> unsetenv("LD_PRELOAD") in main() so it wouldn't propagate to the process
> being tested).  It indicated some minor contention, but not enough to be
> the problem.  Regardless, I converted everything I could to lockfree
> structures (TaskPool and ConstString) and it didn't help.
>
> 2. I tried strace, but I don't think strace can figure out how to trace
> lldb.  It says it waits on a single futex for 8 seconds, and then is done.
>
> I'm about to try lttng to trace all syscalls, but I was wondering if
> anyone else had any ideas?  At one point I wondered if it was mmap kernel
> semaphore contention, but that shouldn't affect faulting individual pages,
> and I assume lldb doesn't call mmap all the time.
>
> I'm getting a bit frustrated because lldb should be taking 1-2 seconds to
> start up (it has ~45s of user+system work to do), but instead is taking
> 8-10, and I've been stuck there for a while.
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Lack of parallelism

[Jim Ingham via lldb-dev]

I'm not sure about Linux, on OS X lldb will mmap the debug information rather 
that using straight reads.  But that should just be once per loaded module.

Jim

> On May 2, 2017, at 8:09 AM, Scott Smith via lldb-dev 
>  wrote:
> 
> I've been trying to improve the parallelism of lldb but have run into an odd 
> roadblock.  I have the code at the point where it creates 40 worker threads, 
> and it stays that way because it has enough work to do.  However, running 
> 'top -d 1' shows that for the time in question, cpu load never gets above 4-8 
> cpus (even though I have 40).
> 
> 1. I tried mutrace, which measures mutex contention (I had to call 
> unsetenv("LD_PRELOAD") in main() so it wouldn't propagate to the process 
> being tested).  It indicated some minor contention, but not enough to be the 
> problem.  Regardless, I converted everything I could to lockfree structures 
> (TaskPool and ConstString) and it didn't help.
> 
> 2. I tried strace, but I don't think strace can figure out how to trace lldb. 
>  It says it waits on a single futex for 8 seconds, and then is done.
> 
> I'm about to try lttng to trace all syscalls, but I was wondering if anyone 
> else had any ideas?  At one point I wondered if it was mmap kernel semaphore 
> contention, but that shouldn't affect faulting individual pages, and I assume 
> lldb doesn't call mmap all the time.
> 
> I'm getting a bit frustrated because lldb should be taking 1-2 seconds to 
> start up (it has ~45s of user+system work to do), but instead is taking 8-10, 
> and I've been stuck there for a while.
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

Re: [lldb-dev] Parallelizing loading of shared libraries

[Scott Smith via lldb-dev]

LLDB has TaskRunner and TaskPool.  TaskPool is nearly the same as
llvm::ThreadPool.  TaskRunner itself is a layer on top, though, and doesn't
seem to have an analogy in llvm.  Not that I'm defending TaskRunner

I have written a new one called TaskMap.  The idea is that if all you want
is to call a lambda over the values 0 .. N-1, then it's more efficient to
use std::atomic rather than various std::function with std::future
and std::bind and std::. for each work item.  It is also a layer on top
of TaskPool, so it'd be easy to port to llvm::ThreadPool if that's how we
end up going. It ends up reducing lock contention within TaskPool without
needing to fall back on a lockfree queue.

On Tue, May 2, 2017 at 6:44 AM, Zachary Turner  wrote:

> Fwiw I haven't even followed the discussion closely enough to know what
> the issues with the lldb task runner even are.
>
> My motivation is simple though: don't reinvent the wheel.
>
> Iirc LLDB task runner was added before llvm's thread pool existed (I
> haven't checked, so i may be wrong about this). If that's the case, I would
> just assume replace all existing users of lldb task runner with llvm's as
> well and delete lldb's
>
> Regarding the issue with making debugging harder, llvm has functions to
> set thread name now. We could name all threadpool threads
> On Tue, May 2, 2017 at 3:05 AM Pavel Labath via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> On 1 May 2017 at 22:58, Scott Smith  wrote:
>> > On Mon, May 1, 2017 at 2:42 PM, Pavel Labath  wrote:
>> >>
>> >> Besides, hardcoding the nesting logic into "add" is kinda wrong.
>> >> Adding a task is not the problematic operation, waiting for the result
>> >> of one is. Granted, generally these happen on the same thread, but
>> >> they don't have to be -- you can write a continuation-style
>> >> computation, where you do a bit of work, and then enqueue a task to do
>> >> the rest. This would create an infinite pool depth here.
>> >
>> >
>> > True, but that doesn't seem to be the style of code here.  If it were
>> you
>> > wouldn't need multiple pools, since you'd just wait for the callback
>> that
>> > your work was done.
>> >
>> >>
>> >>
>> >> Btw, are we sure it's not possible to solve this with just one thread
>> >> pool. What would happen if we changed the implementation of "wait" so
>> >> that if the target task is not scheduled yet, we just go ahead an
>> >> compute it on our thread? I haven't thought through all the details,
>> >> but is sounds like this could actually give better performance in some
>> >> scenarios...
>> >
>> >
>> > My initial reaction was "that wouldn't work, what if you ran another
>> posix
>> > dl load?"  But then I suppose *it* would run more work, and eventually
>> you'd
>> > run a leaf task and finish something.
>> >
>> > You'd have to make sure your work could be run regardless of what
>> mutexes
>> > the caller already had (since you may be running work for another
>> > subsystem), but that's probably not too onerous, esp given how many
>> > recursive mutexes lldb uses..
>>
>> Is it any worse that if the thread got stuck in the "wait" call? Even
>> with a dead-lock-free thread pool the task at hand still would not be
>> able to make progress, as the waiter  would hold the mutex even while
>> blocked (and recursiveness will not save you here).
>>
>> >
>> > I think that's all the more reason we *should* work on getting
>> something into LLVM first.  Anything we already have in LLDB, or any
>> modifications we make will likely not be pushed up to LLVM, especially
>> since LLVM already has a ThreadPool, so any changes you make to LLDB's
>> thread pool will likely have to be re-written when trying to get it to
>> LLVM.  And since, as you said, more projects depend on LLVM than LLDB,
>> there's a good chance that the baseline you'd be starting from when making
>> improvements is more easily adaptable to what you want to do.  LLDB has a
>> long history of being shy of making changes in LLVM where appropriate, and
>> myself and others have started pushing back on that more and more, because
>> it accumulates long term technical debt.
>> > In my experience, "let's just get it into LLDB first and then work on
>> getting it up to LLVM later" ends up being "well, it's in LLDB now, so
>> since my immediate problem is solved I may or may not have time to revisit
>> this in the future"  (even if the original intent is sincere).
>> > If there is some resistance getting changes into LLVM, feel free to add
>> me as a reviewer, and I can find the right people to move it along.  I'd
>> still like to at least hear a strong argument for why the existing
>> implementation in LLVM is unacceptable for what we need.  I'm ok with "non
>> optimal".  Unless it's "unsuitable", we should start there and make
>> incremental improvements.
>>
>> I think we could solve our current problem by just having two global
>> instances of llvm::ThreadPool. The only issue I have with that is that
>> I will then have 

[lldb-dev] LLDB/NetBSD May

[Kamil Rytarowski via lldb-dev]

I put a summary of April achievements here:

http://blog.netbsd.org/tnf/entry/lldb_netbsd_process_plugin_enhancements

The plan for the next milestone is continuing development of threads in
the NetBSD Process Plugin. I will need to work more on correctness of
ptrace(2) calls as new issues were detected in setups with threads that
resulted in crashes.

There is also ongoing work on a new build node running NetBSD-current
(prerelease of 8) and building LLVM+Clang+LLDB. I'm working on enabling
unit tests to catch functional regressions quickly. The original LLDB
node cluster was privately funded by myself in the last two years and
has been switched to a machine hosted by The NetBSD Foundation.

To keep this machine up and running (8 CPU, 24 GB RAM) community support
through donations is required. This is crucial to actively maintain the
LLVM toolchain (Clang, LLDB and others) on NetBSD.




signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Lack of parallelism

[Scott Smith via lldb-dev]

As it turns out, it was lock contention in the memory allocator.  Using
tcmalloc brought it from 8+ seconds down to 4.2.

I think this didn't show up in mutrace because glibc's malloc doesn't use
pthread mutexes.

Greg, that joke about adding tcmalloc wholesale is looking less funny and
more serious  Or maybe it's enough to make it a cmake link option (use
if present or use if requested).

On Tue, May 2, 2017 at 8:42 AM, Jim Ingham  wrote:

> I'm not sure about Linux, on OS X lldb will mmap the debug information
> rather that using straight reads.  But that should just be once per loaded
> module.
>
> Jim
>
> > On May 2, 2017, at 8:09 AM, Scott Smith via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > I've been trying to improve the parallelism of lldb but have run into an
> odd roadblock.  I have the code at the point where it creates 40 worker
> threads, and it stays that way because it has enough work to do.  However,
> running 'top -d 1' shows that for the time in question, cpu load never gets
> above 4-8 cpus (even though I have 40).
> >
> > 1. I tried mutrace, which measures mutex contention (I had to call
> unsetenv("LD_PRELOAD") in main() so it wouldn't propagate to the process
> being tested).  It indicated some minor contention, but not enough to be
> the problem.  Regardless, I converted everything I could to lockfree
> structures (TaskPool and ConstString) and it didn't help.
> >
> > 2. I tried strace, but I don't think strace can figure out how to trace
> lldb.  It says it waits on a single futex for 8 seconds, and then is done.
> >
> > I'm about to try lttng to trace all syscalls, but I was wondering if
> anyone else had any ideas?  At one point I wondered if it was mmap kernel
> semaphore contention, but that shouldn't affect faulting individual pages,
> and I assume lldb doesn't call mmap all the time.
> >
> > I'm getting a bit frustrated because lldb should be taking 1-2 seconds
> to start up (it has ~45s of user+system work to do), but instead is taking
> 8-10, and I've been stuck there for a while.
> >
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] NetBSD core(5) files for LLDB's test-suite

[Kamil Rytarowski via lldb-dev]

On 02.05.2017 16:50, Pavel Labath wrote:
> Sorry it took me so long. I think it's fine to check a couple of those
> in. When zipped, they will still be orders of magnitude smaller then
> the windows minidump exe we are carrying around.
> 
> For the long term though, I'd like to add the necessary support to
> llvm's obj2yaml to be able to generate these. As far as I can tell, it
> just needs program header support added. Then we will be able to
> generate truly small unit tests (e.g. by removing all the memory
> segments for tests that only need threads signal or registers and
> such).

Sounds good with obj2yaml.

I'm willing to contribute needed code parts in obj2yaml when needed.



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Lack of parallelism

[Greg Clayton via lldb-dev]

The other thing would be to try and move the demangler to use a custom 
allocator everywhere. Not sure what demangler you are using when you are doing 
these tests, but we can either use the native system one from the #include 
, or the fast demangler in FastDemangle.cpp. If it is the latter, 
then we can probably optimize this. 

The other thing to note is local files will be mmap'ed in and paging doesn't 
really show up on perf tests very well, so it will look like system time when 
the system is paging in pages from the symbol files as it reads them from 
memory. You could try disabling the mmap stuff in DataBufferLLVM.cpp and see if 
you see any difference. The call to llvm::MemoryBuffer::getFileSlice() takes a 
Volatile as its last argument. If you set this to true, we will read the file 
into memory instead of mmap'ing it. This will help you at least see if there is 
any component of the time that is due to mmap'ing. Currently we look to see if 
the file is local (not on a network mount). If it is local we mmap it. 

Greg


> On May 2, 2017, at 12:31 PM, Scott Smith  wrote:
> 
> As it turns out, it was lock contention in the memory allocator.  Using 
> tcmalloc brought it from 8+ seconds down to 4.2.
> 
> I think this didn't show up in mutrace because glibc's malloc doesn't use 
> pthread mutexes.
> 
> Greg, that joke about adding tcmalloc wholesale is looking less funny and 
> more serious  Or maybe it's enough to make it a cmake link option (use if 
> present or use if requested).
> 
> On Tue, May 2, 2017 at 8:42 AM, Jim Ingham  > wrote:
> I'm not sure about Linux, on OS X lldb will mmap the debug information rather 
> that using straight reads.  But that should just be once per loaded module.
> 
> Jim
> 
> > On May 2, 2017, at 8:09 AM, Scott Smith via lldb-dev 
> > mailto:lldb-dev@lists.llvm.org>> wrote:
> >
> > I've been trying to improve the parallelism of lldb but have run into an 
> > odd roadblock.  I have the code at the point where it creates 40 worker 
> > threads, and it stays that way because it has enough work to do.  However, 
> > running 'top -d 1' shows that for the time in question, cpu load never gets 
> > above 4-8 cpus (even though I have 40).
> >
> > 1. I tried mutrace, which measures mutex contention (I had to call 
> > unsetenv("LD_PRELOAD") in main() so it wouldn't propagate to the process 
> > being tested).  It indicated some minor contention, but not enough to be 
> > the problem.  Regardless, I converted everything I could to lockfree 
> > structures (TaskPool and ConstString) and it didn't help.
> >
> > 2. I tried strace, but I don't think strace can figure out how to trace 
> > lldb.  It says it waits on a single futex for 8 seconds, and then is done.
> >
> > I'm about to try lttng to trace all syscalls, but I was wondering if anyone 
> > else had any ideas?  At one point I wondered if it was mmap kernel 
> > semaphore contention, but that shouldn't affect faulting individual pages, 
> > and I assume lldb doesn't call mmap all the time.
> >
> > I'm getting a bit frustrated because lldb should be taking 1-2 seconds to 
> > start up (it has ~45s of user+system work to do), but instead is taking 
> > 8-10, and I've been stuck there for a while.
> >
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org 
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
> > 
> 
> 

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

Re: [lldb-dev] Lack of parallelism

[Scott Smith via lldb-dev]

On Tue, May 2, 2017 at 12:43 PM, Greg Clayton  wrote:

> The other thing would be to try and move the demangler to use a custom
> allocator everywhere. Not sure what demangler you are using when you are
> doing these tests, but we can either use the native system one from
> the #include , or the fast demangler in FastDemangle.cpp. If it
> is the latter, then we can probably optimize this.
>

I'm using the demangler I modified here: https://reviews.llvm.org/D32500
I think it still starts with FastDemangle.cpp, but one test showed the
modified llvm demangler is almost as fast (~1.25% slow down by disabling
FastDemangle).  I might be able to narrow that further by putting the
initial arena on the stack.

Now that I moved past the parallelism bottleneck, I think I need to revisit
my changes to make sure they're having the desired effect.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB/NetBSD May

[Kamil Rytarowski via lldb-dev]

On 02.05.2017 21:48, Christos Zoulas wrote:
> On May 2,  9:06pm, n...@gmx.com (Kamil Rytarowski) wrote:
> -- Subject: LLDB/NetBSD May
> 
> | I put a summary of April achievements here:
> | 
> | http://blog.netbsd.org/tnf/entry/lldb_netbsd_process_plugin_enhancements
> 
> Thanks, that looks great.
> 
> | The plan for the next milestone is continuing development of threads in
> | the NetBSD Process Plugin. I will need to work more on correctness of
> | ptrace(2) calls as new issues were detected in setups with threads that
> | resulted in crashes.
> 
> Makes sense. I will try to help.
>  

I built the kernel with all debug options and diagnostics.. and the
crashes disappeared.

On the other hand with these options enabled "resume1" started to fail,
a test from our ATF regression unit tests in t_ptrace_wait*.

There are two bugs:
 1. kernel crashes with threads in the local copy of Process Plugin.
 2. PT_SUSPEND, PT_RESUME unreliable http://gnats.netbsd.org/51995

I'm working on (1.) now.

If possible please help with (2.) as there are ATF tests ready and no
need to setup LLVM+Clang+LLDB.

Index: GENERIC
===
RCS file: /cvsroot/src/sys/arch/amd64/conf/GENERIC,v
retrieving revision 1.457
diff -u -r1.457 GENERIC
--- GENERIC 18 Apr 2017 19:09:12 -  1.457
+++ GENERIC 2 May 2017 19:57:36 -
@@ -91,14 +91,14 @@
 # Diagnostic/debugging support options
 optionsDIAGNOSTIC  # inexpensive kernel consistency checks
# XXX to be commented out on release branch
-#options   DEBUG   # expensive debugging checks/support
-#options   LOCKDEBUG   # expensive locking checks/support
+optionsDEBUG   # expensive debugging checks/support
+optionsLOCKDEBUG   # expensive locking checks/support

 #
 # Because gcc omits the frame pointer for any -O level, the line below
 # is needed to make backtraces in DDB work.
 #
-makeoptionsCOPTS="-O2 -fno-omit-frame-pointer"
+makeoptionsCOPTS="-O0 -g -fno-inline -fno-omit-frame-pointer"
 optionsDDB # in-kernel debugger
 #options   DDB_COMMANDONENTER="bt" # execute command when ddb is entered
 #options   DDB_ONPANIC=1   # see also sysctl(7): `ddb.onpanic'


> | There is also ongoing work on a new build node running NetBSD-current
> | (prerelease of 8) and building LLVM+Clang+LLDB. I'm working on enabling
> | unit tests to catch functional regressions quickly. The original LLDB
> | node cluster was privately funded by myself in the last two years and
> | has been switched to a machine hosted by The NetBSD Foundation.
> | 
> | To keep this machine up and running (8 CPU, 24 GB RAM) community support
> | through donations is required. This is crucial to actively maintain the
> | LLVM toolchain (Clang, LLDB and others) on NetBSD.
> 
> Why don't we run this in one of our machines?
> 

It's already there! (talia.netbsd.org)

For details there is need to talk our admins.

> christos
> 




signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev