| Issue |
174663
|
| Summary |
lldb is reads (zeroed) mini-debuginfo's .text file, showing zeroed disassembly instead of real .text section
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
mhansen
|
Hi, I was just debugging an issue on Android.
```
$ ANDROID_SERIAL=57241JEBF08806 adb shell getprop ro.build.fingerprint
google/tegu/tegu:16/BP3A.251005.004.B1/14042072:userdebug/dev-keys
```
I pull `libart.so` to host so I can disassemble it:
```
$ ANDROID_SERIAL=57241JEBF08806 adb pull /apex/com.android.art/lib64/libart.so
```
I try disassembling the function `artQuickGenericJniTrampoline`. This name is stored in the mini debuginfo:
```
$ ~/Android/Sdk/ndk/29.0.14206865/toolchains/llvm/prebuilt/linux-x86_64/bin/lldb --batch -o "file libart.so" -o "disassemble --name artQuickGenericJniTrampoline" | head
(lldb) file libart.so
Current executable set to '/usr/local/google/home/markhansen/2025-12-16/libart.so' (aarch64).
(lldb) disassemble --name artQuickGenericJniTrampoline
libart.so`artQuickGenericJniTrampoline:
libart.so[0x29e51c] <+0>: udf #0x0
libart.so[0x29e520] <+4>: udf #0x0
libart.so[0x29e524] <+8>: udf #0x0
libart.so[0x29e528] <+12>: udf #0x0
libart.so[0x29e52c] <+16>: udf #0x0
libart.so[0x29e530] <+20>: udf #0x0
```
I just get zeros; `udf` is the zero instruction in ARM. I think this is because the mini-debuginfo is an ELF object containing a few sections, including a `.text` section. I think with how LLDB has implemented mini-debuginfo, it loads the minidebuginfo, and then the empty `.text` section from the minidebuginfo shadows the real `.text` from the `libart.so`.
We can see that the text has a virtual size, but is has no contents:
```
$ llvm-objcopy --dump-section .gnu_debugdata=minidebug.xz libart.so
$ xz -d minidebug.xz
$ llvm-readelf -S minidebug
There are 6 section headers, starting at offset 0x1ce370:
Section Headers:
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
[ 0] NULL 0000000000000000 000000 000000 00 0 0 0
[ 1] .text NOBITS 0000000000200000 000000 743b5c 00 AX 0 0 16384
[ 2] .strtab STRTAB 0000000000000000 000040 175e76 00 0 0 16384
[ 3] .symtab SYMTAB 0000000000000000 175eb6 058488 18 2 1 8
[ 4] .debug_frame PROGBITS 0000000000000000 1ce33e 000000 00 0 0 8
[ 5] .shstrtab STRTAB 0000000000000000 1ce33e 00002e 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
R (retain), p (processor specific)
$ llvm-objcopy --dump-section .text=.text minidebug
llvm-objcopy: error: 'libart.so': cannot dump section '.text': it has no contents
```
GDB is able to disassemble this correctly - note the instructions aren't all `udf`.
```
$ gdb-multiarch --batch --eval "file libart.so" --eval "disassemble artQuickGenericJniTrampoline" | head
Dump of assembler code for function artQuickGenericJniTrampoline:
0x000000000029e51c <+0>: sub sp, sp, #0x150
0x000000000029e520 <+4>: stp x29, x30, [sp, #240]
0x000000000029e524 <+8>: stp x28, x27, [sp, #256]
0x000000000029e528 <+12>: stp x26, x25, [sp, #272]
0x000000000029e52c <+16>: stp x24, x23, [sp, #288]
0x000000000029e530 <+20>: stp x22, x21, [sp, #304]
0x000000000029e534 <+24>: stp x20, x19, [sp, #320]
0x000000000029e538 <+28>: add x29, sp, #0xf0
```
So I think this is a bug in how LLDB is interpreting minidebuginfo.
I've attached the libart.so (gzipped so that GitHub will accept it): [libart.so.gz](https://github.com/user-attachments/files/24460889/libart.so.gz)
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
