[lldb-dev] lldb command like gdb's "set auto-solib-add off"
Ted Woodward via lldb-dev
lldb-dev at lists.llvm.org
Mon May 22 16:23:29 PDT 2017
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 system in /local/scratch/work/debuglibs , you can say
target modules search-paths add /usr/lib /local/scratch/work/debuglibs
and when lldb goes to load (for example) /usr/lib/libc.so, it will try to load /local/scratch/work/debuglibs/libc.so from the host machine before trying to load through the memory interface.
I found this very helpful when trying to debug dynamic executables on Linux running on a Hexagon board, running lldb on x86 Linux or Windows.
Ted
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
> -----Original Message-----
> From: lldb-dev [mailto:lldb-dev-bounces at lists.llvm.org] On Behalf Of Jim
> Ingham via lldb-dev
> Sent: Monday, May 22, 2017 5:02 PM
> To: Chunseok Lee <chunseoklee at gmail.com>
> Cc: lldb-dev <lldb-dev at lists.llvm.org>
> Subject: Re: [lldb-dev] lldb command like gdb's "set auto-solib-add off"
>
> 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 "add-symbol-file" to
> manually point lldb at the host-side symbol files. If you are reading symbols
> from host-side files, then symbol loading doesn't slow down debugging
> startup that much.
>
> Presumably, your symbol files are only on the device, so you are reading
> them from memory. "settings set target.memory-module-load-level" is
> almost what you want, but it applies to ALL shared libraries read from
> memory. If you can copy the symbol file that contains the
> __jit_debug_register_code to the host you are debugging from, and use
> add-symbol-file to tell lldb about it, then that one should NOT have to be
> read from memory anymore. Then you could turn "memory-module-load-
> level" to partial or even mininal, and that should get you starting faster.
>
> The other option would be to extend the setting, so you can say:
>
> set set target.memory-module-load-level [[lib-name level] [lib-name level]
> ...]
>
> If there's just one argument, that's equivalent to "all <arg>".
>
> Jim
>
> > On May 22, 2017, at 2:35 PM, Chunseok Lee <chunseoklee at gmail.com>
> wrote:
> >
> >
> >
> > 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 so many shared libs. since I am debuggging with gdbjit
> feature, I do not need shared library loading except one shared lib(which
> contains __jit_debug_register_code symbol) Thus, I want to turn off shred
> lib loading except one shared lib. Is it possible?
> >
> > Thank you.
> >
> > BR,
> > Chunseok Lee
> >
> >
> >
> > 2017. 5. 23. 오전 3:24 Jim Ingham <jingham at apple.com> 작성:
> >
> >> 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 loading
> breakpoint is getting set with a global search which is pulling in all the symbols
> from all the initially loaded shared libraries. It would be better to fix things so
> that only explicit user actions (which can be scoped to shared libraries to limit
> the search) pull in symbols so we don't have to fiddle around with turning off
> and on the loading of shared libraries. Back when we were supporting gdb
> for MacOS I did a lot of work to try to get this right (there are times you really
> need the shared library info - e.g. when something shows up in a backtrace)
> so you have to judiciously re-introduce symbols, or the user experience is
> noticeably degraded.
> >>
> >> It also depends on how far you want to go turning this off. There's "don't
> look at shared libraries at all" which is what the auto-solib-add variable does
> IIRC. We also had a fairly extensive mechanism to specify "load-levels" for
> various libraries, which was more user-friendly but much more work to
> support. Anyway, it would be easy to just turn this shared library
> notifications - just don't set the dyld load notification breakpoint. That would
> be the easy part. But as I said above, you're also going to have to make sure
> you turn it back on for users when some action they request requires it.
> >>
> >> Note, there is a setting to determine how much symbol information to
> read in from libraries loaded from memory (since in device debugging this
> can be quite slow.) That is the target.memory-module-load-level setting.
> You might look at that for some hints as to how to proceed.
> >>
> >> Jim
> >>
> >>> On May 22, 2017, at 8:02 AM, Chunseok Lee via lldb-dev <lldb-
> dev at lists.llvm.org> 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
> >>> _______________________________________________
> >>> lldb-dev mailing list
> >>> lldb-dev at lists.llvm.org
> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
More information about the lldb-dev
mailing list