> On Apr 13, 2017, at 9:06 AM, Scott Smith via lldb-dev
> wrote:
>
> Ok. I tried doing something similar to gdb but was unable to make any
> headway because they have so many global variables. It looked more promising
> with lldb since there were already some locks.
>
> I assume you're tal
Ok. I tried doing something similar to gdb but was unable to make any
headway because they have so many global variables. It looked more
promising with lldb since there were already some locks.
I assume you're talking about check-lldb?
https://lldb.llvm.org/test.html
I'll work on getting those
I've have looked at paralelization of the module loading code some time
ago, albeit with a slightly different use case in mind. I eventually
abandoned it (at least temporarily) because I could not get it to work
correctly for all use cases.
I do think that doing this is a good idea, but I think it
The POSIX dynamic loader processes one module at a time. If you have a lot
of shared libraries, each with a lot of symbols, this creates unneeded
serialization (despite the use of TaskRunners during symbol loading, there
is still quite a bit of serialization when loading a library).
In order to p
