This may cause some issues with the multi-configuration generators.
E.g. a single VS build will create both debug and release
configurations. I suspect this is the reason why the check is written
as it is now.
I'm not sure what would be the appropriate behavior in this case if
only one of the pyth
Note to apple folks: The lldb-server test suite is also used for
testing debugserver. I'm not sure how much you guys care about these
tests (the commit history shows only Todd touched them), but we would
be interested in hearing your thoughts on this.
On 16 May 2017 at 12:08, Pavel Labath wrote:
Hello.
In gdb, I can toggle auto symbol loading using "set auto-solib-add off" command.
I wonder that lldb has similar command for disabling auto shared library symbol
loading?
If not, where is the good starting point to review the source code to implement
this feature?
BR,
Chunseok Lee__
We designed lldb to be as lazy as possible in loading symbol information from
the shared libraries as they get loaded. If this is causing you problems, the
first thing to do is to figure out why lldb is pulling in more information than
you need. For instance, it looks like on Linux the gdb JIT
My dev machine has both debug and release python exe/lib/dll installed; The VS
solution made by cmake works fine building debug and release versions of lldb.
Our bots only have release exe/lib, and create a VS solution with cmake and
build with msbuild.
--
Qualcomm Innovation Center, Inc.
The Q
Thank you for your help.
It would be really helpful to me.
The reason behind the question is exactly what you mentioned. I am wokring on
debugging in devices and it seems that shared library loading(I do not know
lldb loads symbols lazyly) runs very slowly since my testing program depends on
In general, if lldb can find host-side copies of binaries that match the ones
it finds on the device, it will do all symbol reading against the host copies.
In the case of an OS X host debugging iOS, lldb uses Spotlight and a few other
tricks to find the host-side binaries. You can also use "a
To expand on Jim's message, "target modules search-paths add" can be used to
help lldb find the host-side copies of shared libraries when they're not in
the same directory as on the target system.
For example, if you have libraries in /usr/lib on the target system, and have
copies on the host
