Hi Emre, I have to say I'm pretty sceptical about this approach, for all the reasons that Jim already mentioned. Making it so that lldb pretends the other shared libraries don't exist (which is what I assume your prototype does) is fairly easy, but it does create a very long tail of "feature X does not work in this mode" problems (my app crashed in a third-party library -- maybe because I passed it a wrong argument -- but I cannot even unwind into my code to see what I passed).
It's the fixing these problems that will make the solution very complicated. On 08/05/2020 22:21, Jim Ingham via lldb-dev wrote: > Note, if you are reading the binaries out of memory from the device, and > don’t have local symbols, things go much more slowly. gdb-remote is NOT > a high bandwidth protocol, and fetching all the symbols through a series > of memory reads is pretty slow. lldb does have a setting to control > what you do with binaries that don’t exist on the host > (target.memory-module-load-level) that controls this behavior. But it > just deals with what we do and don’t read and makes no attempt to > ameliorate the fallout from having a reduced view of the symbols in the > program. We don't load modules from memory on android (with elf that doesn't even work right now in lldb). We download files directly via the adb protocol, which is much faster than gdb-remote's qFile. So I'm afraid the problem is going to be more complicated than that. pl _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
