rchamala wrote: > I'd like to get a better understanding of what you're trying to achieve: > > Does the child elf-core process doesn't have any module loaded ? Are they > only described in the tombstone and require to be downloaded which could > potentially fail ?
Child elf-core process has module information for shared libraries directly loaded from the shared library file(.so file) but does not have module information from the ones loaded from .apk. For an Android app runtime, some shared libraries are directly loaded from .so files and some are loaded from .apk. Apk is like a compressed file used by the installer to run the app and contains all artifacts needed to run the app which includes shared libraries. Due to the limitation in Android Kernel as explained [here](https://discourse.llvm.org/t/load-tombstones-and-coredumps-plugins-together-in-lldb/84190/19), the coredump generated from Android kernel does not dump program headers for the shared libraries in .apk. Note that Android linker when running the Android app, is able to understand the shared libraries inside .apk, can mmap the address of all shared libraries in _/proc/PID/maps_ correctly and can run the app correctly. [Tombstone](https://source.android.com/docs/core/tests/debug) is basically extracted from the live memory map in _/proc/PID/maps_, and has information about all shared libraries and their load addresses. Additionally, tombstone has thread names which are not contained in coredump. So, our design is as follows for the parent scripted process: 1. All the read memory api's to read memory regions from coredump file are used from child elf-core process 2. Get all modules(shared library name & load address), thread names from tombstone file We use [locate module callback](https://github.com/llvm/llvm-project/blob/a57e58dbfaae0e86eb5cafeddf8b598f14b96e36/lldb/source/Target/Platform.cpp#L1593) to fetch the module from our symbol server during lldb process creation. For scripted process, when we call [target.GetOrCreatemodule](https://github.com/llvm/llvm-project/blob/ed38d6702f7695092c9486016e2504f8c6bfef37/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp#L468C16-L468C33) the module callback is called to fetch the module from symbol server. When the symbol is not found or [when the module is already appended](https://github.com/llvm/llvm-project/blob/ed38d6702f7695092c9486016e2504f8c6bfef37/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp#L495), ScriptedProcess method GetLoadedDynamicLibrariesInfos is designed to fail and [skips loading all modules without loading to target](https://github.com/llvm/llvm-project/blob/ed38d6702f7695092c9486016e2504f8c6bfef37/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp#L498). Due to this, all modules end up not being loaded. My request is to return [the successful loaded modules in target](https://github.com/llvm/llvm-project/blob/ed38d6702f7695092c9486016e2504f8c6bfef37/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp#L502C10-L502C24) when ScriptedProcess is asked to get loaded dynamic libraries instead of returning nothing. Please let m e know if you have more questions https://github.com/llvm/llvm-project/pull/127153 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
