[lldb-dev] lldb-mi and shared library path

[Greg Clayton via lldb-dev]

> On Feb 4, 2016, at 1:51 PM, Ted Woodward via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> I’d expect “-gdb-set solib-search-path” to call “target modules search-paths add”, and it does, but only when the –target-remote command is issued. It also doesn’t handle the multiple path case, <path>:<path>…
>  
> I think it should:
>  
> 1)      Set the search path immediately when called, if the target is connected
> 2)      Set the search path on run/attach
> 3)      Handle multiple paths
>  
> Any thoughts on this?
>  

Here are some thoughts that say kind of how we are doing things, and after reading this it might adjust your request:

In LLDB the approach we have taken is that when you are going to remotely debug something, your Platform is responsible for finding any remote file paths might not match the local file paths. 

For Apple with iOS, we have one or more root directories available for us to grab system files from (everything from /usr/lib/* /System/Library/Frameworks, etc). Only the executables you just built tend to exist outside of the system roots, so as long as your provide those to LLDB prior to running ("target create /path/to/locally/built/cross/executable"), we will be able to match up the binaries using their UUID even if the remote path is "/users/admin/executable". There are also ways to say "I built /path/to/locally/built/cross/executable and /path/to/locally/built/cross/libfoo.so and /path/to/locally/built/cross/libbar.so", now attach to a remote binary to debug these things. The extra .so files can be added to your target with "target module add /path/to/locally/built/cross/libfoo.so" and "target module add /path/to/locally/built/cross/libbar.so" and then we will be able to find these files when they are needed.

So the main questions becomes: if you modify your platform to do the right thing, do you need any of the changes you are requesting ("-gdb-set solib-search-path" or "target modules search-paths add")?

This is how things were done back with GDB, but in LLDB we are trying to make our Platform subclasses do a lot of this hard work for us. Your Platform could check with a build server and download and cache any binaries it needed. It could look through a set of directories or other commonly used areas for these files, it really depends on how your SDK/PDK is setup and how your builds tend to happen. If you have an IDE that is creating binaries, it typically knows about all of the build products you might be trying to debug, and it can often supply the build products to LLDB in case it needs them.

Let me know.

Greg Clayton