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

[Ted Woodward via lldb-dev]

The Hexagon SDK taking to hardware is very bare bones. The OS is sitting on the phone and is loaded to the Hexagon by Android. The debugger opens the OS elf file, the user tells it where the shared libraries are, and lldb does the usual stop-at-the-rendezvous function negotiation to get info when shared libraries are loaded. Each example application is its own shared library, and each is built in a different directory. I don't think I can have the Platform do the hard work, because the shared libraries could be anywhere.

It works fine when we run lldb; it doesn't when our Eclipse guy runs lldb-mi. I'm having fun looking at lots of logs!

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

-----Original Message-----
From: Greg Clayton [mailto:gclayton at apple.com] 
Sent: Monday, February 22, 2016 6:24 PM
To: Ted Woodward
Cc: LLDB
Subject: Re: [lldb-dev] lldb-mi and shared library path


> 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