Ok, sounds like you first need to see if "-gdb-set solib-search-path" is hooked up to "target modules search-paths add". If not, hook it up. Then we probably need to add a function to Platform.cpp that can use a target's module search paths to help find an executable. This can probably be a virtual function in Platform.h/cpp that will work for all platforms. So then each platform would try to locate the binary on its own using Platform::ResolveExecutable(...) or Platform::ResolveRemotePath(...) we should use the target's module search paths as places to look. This means that Platform::ResolveRemotePath(...) might need to take a Target list Platform::ResolveExecutable(...) already does. Does that make sense?
Greg > On Feb 22, 2016, at 5:07 PM, Ted Woodward <ted.woodw...@codeaurora.org> wrote: > > 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:gclay...@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@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 > > > _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
