[gdb-remote mode] LLDB fails to automatically load symbols for lib.so on Android and fails to set breakpoints
- Dominant language
- LLVM
- Stars
- 40.5k
- Forks
- 18.7k
- PR merge metrics
- PR metrics pending
Description
During a remote debug session on an Android device (using gdb-remote connection), LLDB fails to automatically determine and set the correct load address for shared libraries (e.g., `libexample.so`). This occurs despite the library being correctly reported in the SVR4 library list returned by the remote stub.
Manual inspection of the `qXfer:libraries-svr4:read` packet reveals that the library is present with the correct `l_addr`, but LLDB does not seem to utilize this information to map the local module to the correct memory location. This leads to unresolved breakpoints
Unable to set breakpoints to functions like
````rust
#[unsafe(no_mangle)]
pub extern "C" fn Java_com_example_app_stringFromJNI<'caller>
````
Current Workaround
1. The user must manually execute the following steps in the LLDB console:
```
script import re; res = lldb.SBCommandReturnObject(); lldb.debugger.GetCommandInterpreter().HandleCommand("process plugin packet send qXfer:libraries-svr4:read::0,ffff", res); match = re.search(r']*/>', res.GetOutput() or ""); print(match.group(0) if match else "libexample.so not found in XML")
```
2. Manually load the module at that address:
```
target modules load -f "/path/to/local/libexample.so" -s
Contributor guide
Assessment
This issue has not been assessed yet.