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.
>
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 fa
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
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 su
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 seriou
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 det
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 cal
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 in
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> wro
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
abo
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 the
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 com
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
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 l
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.o
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 sa
16 matches
Mail list logo
