I'm building an lldb plugin on Mac OS X and Linux using the SB API. This
means downloading the right headers to build against for the level of lldb
installed on the machine building the plugin.
On Linux it is trivial to work out which lldb headers to build against,
you just run lldb -version an
What is actually happening is we are stopped and handling the EntryBreakpoint
and are in the process of trying to load all shared libraries, and then a
signal (I am guessing) comes into the lldb-server and causes the target to
resume. Not sure if that is due to the signal passing packet:
$QPass
If the process is restarted by lldb-server then "posix ptrace" should have
some indication about it. Also "posix process" and "posix thread" can be
useful to understand the bigger picture (all of them in lldb-server).
Note: You can enable them by setting LLDB_SERVER_LOG_CHANNELS
and LLDB_DEBUGSERV
BTW, lldb has a setting:
settings set target.process.extra-startup-command
In the Process GDBRemote case if this is set lldb sends whatever packet you
specify to the stub before starting the normal sequence.
We added support in debugserver for a QSetLogging packet, which we use like:
QSetLogg
What I now believe is happening is lldb-server is exiting for some reason and
then the process just runs and still shows the output in LLDB because we hooked
up the STDIO. I see lldb-server exits with an exit code of 0, but no command
had been sent to terminate it. I will track that down.
Also,
The contract with the SB API is that changes are only additive. So you only
need to track versions if there's an API that was added at some point, and you
want to make sure you have a version of the headers with that API. In practice
that means you shouldn't need to keep updating the SB API's
I worked on some performance improvements for lldb 3.9, and was about to
forward port them so I can submit them for inclusion, but I realized there
has been a major performance drop from 3.9 to 4.0. I am using the official
builds on an Ubuntu 16.04 machine with 16 cores / 32 hyperthreads.
Running
The algorithm included in ObjectFileELF.cpp performs a byte at a time
computation, which causes long pipeline stalls in modern processors.
Unfortunately, the polynomial used is not the same one used by the SSE 4.2
instruction set, but there are two ways to make it faster:
1. Work on multiple bytes
Zlib is definitely optional and we cannot make it required.
Did you check to see if llvm has a crc32 function somewhere in Support?
On Wed, Apr 12, 2017 at 12:15 PM Scott Smith via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> The algorithm included in ObjectFileELF.cpp performs a byte at a time
>
I don't know exactly when the 3.9 / 4.0 branches were cut, and what was done
between those two points, but in general we don't expect/want to see
performance regressions like that. I'm more familiar with the perf
characteristics on macos, Linux is different in some important regards, so I
can
I didn't realize that existed; I just checked and it looks like there's
JamCRC which uses the same polynomial. I don't know what "Jam" means in
this context, unless it identifies the polynomial some how? The code is
also byte-at-a-time.
Would you prefer I use JamCRC support code instead, and the
For my app I think it's largely parsing debug symbols tables for shared
libraries. My main performance improvement was to increase the parallelism
of parsing that information.
Funny, gdb/gold has a similar accelerator table (created when you link with
-gdb-index). I assume lldb doesn't know how
It would be nice if we could simply update LLVM's implementation to be
faster. Having multiple implementations of the same thing seems
undesirable, especially if one (fast) implementation is always superior to
some other reason. i.e. there's no reason anyone would ever want to use a
slow implemen
BTW, the JamCRC is used in writing Windows COFF object files, PGO
instrumentation, and PDB Debug Info reading / writing, so any work we do to
make it faster will benefit many parts of the toolchain.
On Wed, Apr 12, 2017 at 12:42 PM Zachary Turner wrote:
> It would be nice if we could simply upda
What about the crc combining? I don't feel comfortable reimplementing that
on my own. Can I leave that as a feature predicated on zlib?
For the JamCRC improvements, I assume I submit that to llvm-dev@ instead?
On Wed, Apr 12, 2017 at 12:45 PM, Zachary Turner wrote:
> BTW, the JamCRC is used
It seems like the the crc32_combine is not too hard to implement, but we do
already have code in LLVM that is predicated on the existence of zlib, so
it seems reasonable to leave it that way. And yes, you would submit those
changes to llvm-dev. Perhaps the JamCRC implementation could be updated t
So the issue is with jModulesInfo. If it is too large we end up losing
connection. Not sure if this is on the send or receive side yet. But if I
comment out support for this packet, my debug sessions works just fine.
Greg
> On Apr 12, 2017, at 10:42 AM, Greg Clayton wrote:
>
> What I now beli
On Wed, Apr 12, 2017 at 10:43 AM Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> What I now believe is happening is lldb-server is exiting for some reason
> and then the process just runs and still shows the output in LLDB because
> we hooked up the STDIO. I see lldb-server exits wit
Ok I stripped out the zlib crc algorithm and just left the parallelism +
calls to zlib's crc32_combine, but only if we are actually linking with
zlib. I left those calls here (rather than folding them info JamCRC)
because I'm taking advantage of TaskRunner to parallelize the work.
I moved the sys
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
I know this is outside of your initial goal, but it would be really great
if JamCRC be updated in llvm to be parallel. I see that you're making use
of TaskRunner for the parallelism, but that looks pretty generic, so
perhaps that could be raised into llvm as well if it helps.
Not trying to throw e
21 matches
Mail list logo
