Before I dive into the code to see if there's a bug, I wanted to see if I was just doing it wrong.
I have an application with a different libc, etc than the machine I'm running the debugger on. The application also has a bunch of libraries that simply don't exist in the normal location on my dev machine. I do have everything extracted in a subdirectory with proper relative paths (i.e. my_extract/lib/..., my_extract/opt/..., my_extract/usr/..., etc). With gdb, I'd do something like: set sysroot . file opt/my_cool_program core my_broken_coredump then everything would work. I've tried ( http://lists.llvm.org/pipermail/lldb-dev/2016-January/009233.html): platform select --sysroot . host (also tried remote-linux, that didn't work either) target create opt/my_cool_program --core my_broken_coredump or based on: http://lists.llvm.org/pipermail/lldb-dev/2016-January/009235.html setting set target.exec-search-paths . target create opt/my_cool_program --core my_broken_coredump or, based on: http://lists.llvm.org/pipermail/lldb-dev/2016-January/009236.html target create opt/my_cool_program --core my_broken_coredump target modules search-paths add /lib ./lib ... None of them seem to work. I tried lldb-3.9 in case any recent changes affected this functionality. Is there a more correct way to do this? Or does this seem like a bug?
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
