Remote ARM32 gdb failes to load symbol files compiled on other hosts

[unknown321]

I am debugging a shared library running on ARMv7 processor, ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV).

(rr) decompiler connect ghidra --base-addr-start 0xb5c0f000 --base-addr-end 0xb67e82b7
[+] Connected to decompiler!
(rr) i br
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0xb5c347ac         <- set from ghidra debugger, works

(rr) b FUN_DEADF00D
Note: breakpoint 1 also set at pc 0xb5c347ac.
Breakpoint 2 at 0xb5c347ac
(rr) i br
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0xb5c347ac         
2       breakpoint     keep y   0x00000000b5c347ac <- new
(rr) c
Continuing.
Remote connection closed
Command aborted.

Remote gdb on device segfaults.

[mahaloz]

@unknown321, huh, well that's a new one. Just to confirm, you have gcc installed on this 32bit device right?

[mahaloz]

Oh and gdb is running on a 32bit host? Or are you running on a 64bit host, then connecting remotely to a 32bit gdb?

[unknown321]

Ghidra and gdb-multiarch are running on 64bit host. Gdb-multiarch is connected to remote 32bit gdb instance on device. No gcc on device.

[mahaloz]

Without testing everything I think all issues are coming from this portion of the code:

decomp2dbg/decomp2dbg/clients/gdb/symbol_mapper.py

Line 224 in 08f3b11

# NOTE: 64-bit elf checks are redundant as of now because all debug files

[mahaloz]

@unknown321 if you want to test a simple fix, try and clone d2d, then edit this line:
https://github.com/mahaloz/decomp2dbg/blob/08f3b1133986847c54abe43797d9203a2c9d0685/decomp2dbg/clients/gdb/symbol_mapper.py#L238C14-L238C14

Force it to always be <I here. Lmk if it works.

[unknown321]

Addresses can be fixed by providing -m32 flag to gcc, breakpoint's address looks fine, but it still segfaults.

Solved the problem by using arm gcc and objcopy versions (arm-linux-gnueabi-*) in environment, which was used to compile that library.

[mahaloz]

@unknown321 I see, so if I am understanding you correctly, you needed to:

1. Have an ELF that was the same arch as the running debugger
2. Have an ELF that was the same bitness as the running debugger
3. Copy objects using same arch binutils as the running debugger

I see. That's somewhat rough. I'm going to leave this issue open, though the root of this issue is that we are not symbolizing correctly. We need #54 to make this work for when you are using remote debugging. I don't fully understand this though since I have had this work remote on arm32 before (demo on the readme).