> 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
We should increase the timeout for this command only. We can do that. Thanks
for the pointer, that will make fixing things much easier!
> On Apr 13, 2017, at 5:48 AM, Tamas Berghammer wrote:
>
> I seen a similar issue when trying to debug an application with a lot of
> shared libraries (1000+)
Interesting. That saves lldb startup time (after crc
improvements/parallelization) by about 1.25 seconds wall clock / 10 seconds
cpu time, but increases linking by about 2 seconds of cpu time (and an
inconsistent amount of wall clock time). That's only a good tradeoff if
you run the debugger a lo
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 seen a similar issue when trying to debug an application with a lot of
shared libraries (1000+) and in that case the problem was that lldb-server
was too slow to respond what caused a connection timeout in lldb.
Increasing plugin.process.gdb-remote.packet-timeout fixed the problem for
me but it w
Bisecting the performance regression would be extremely valuable. If you
want to do that, it would be very appreciated.
On 12 April 2017 at 20:39, Scott Smith via lldb-dev wrote:
> For my app I think it's largely parsing debug symbols tables for shared
> libraries. My main performance improveme
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
There is a good crc32c (assuming we want crc32c) code in DPDK
(BSD-licensed).
http://dpdk.org/browse/dpdk/tree/lib/librte_hash
It has hardware assisted algorithm for x86 and arm64 (if hardware
supports it). There is a fallback to lookup table implementation.
CRC32 is definitely worth merging wit
Improving the checksumming speed is definitely a worthwhile contribution,
but be aware that there is a pretty simple way to avoid computing the crc
altogether, and that is to make sure your binaries have a build ID. This is
generally as simple as adding -Wl,--build-id to your compiler flags.
+1 to
While definitely not a prime example of StringRef usage, it is not strictly
a bug either. Future calls of getopt will modify the value of optarg, but
the actual string it points to (will have pointed to) remains unchanged as
that is just some member of the initial argv array.
That said, I have no
10 matches
Mail list logo
