Enhace/Fix issues in the GDB backend (ARM on RPI)

[radare]

Those are some of the issues I have found debugging a remote gdbserver on RPI with r2:

[0xb6fd8e80]> pd 20
r_reg_get_value: Bit size 96 not supported
r_debug_gdb_reg_read: small buffer 176 vs 200

[0xb6fd8e80]> e asm.bits=64
r_reg_get_value: null or oob arena for current regset
r_reg_get_value: null or oob arena for current regset

Also, the IO is _VERYSLOW (disassembling 2 instructions takes 7 seconds:

[0xb6fd8e80]> ?t pd 2
7.647732

[0xb6fd8e80]> ?t pd 10
11.352022

This slowdown is probably because of the lack of memoization or caching. The speed for plain reads with p8 is quite better:

[0xb6fd8e80]> ?t p8 1024
1.153852
r_debug_gdb_reg_read: small buffer 72 vs 200
[0xb6fd8e80]> ?t p8 32
0.000016
r_debug_gdb_reg_read: small buffer 72 vs 200
[0xb6fd8e80]> ?t p8 4096
2.907238
r_debug_gdb_reg_read: small buffer 72 vs 200
[0xb6fd8e80]>

Setting values to registers doesn't works:

[0xb6fd8e80]> dr r2=33
Error registername <r13> not found in profile
0x7fe7aad00972 ->0x00000021
[0xb6fd8e80]> dr?r2
r_debug_gdb_reg_read: small buffer 72 vs 200
0x00000021

buf if you show ALL the regs:

[0xb6fd8e80]> dr=
r_debug_gdb_reg_read: small buffer 72 vs 200
  lr 0x00000000      pc 0x00000000      r0 0x00000000      r1 0x00000000
  r2 0x00000000      r3 0x00000000      r4 0x00000000      r5 0x00000000
  r6 0x00000000      r7 0x00000000      r8 0x00000000      r9 0x00000000
 r10 0x00000000     r11 0x00000000     r12 0x00000000     r13 0x00000000
 r14 0x00000000     r15 0x00000000     r16 0x00000000     r17 0x00000000
r_debug_gdb_reg_read: small buffer 72 vs 200
[0xb6fd8e80]>

Reading and writing memory seems to work fine, (reading speed must be improved)

[radare]

Some debugging of why 'pd' is slow. Also, i have verified that plain 'pi' is fast.

[0xb6fd8e80]> pd 2
READ 0xb6fd8f18 63
r_reg_get_value: Bit size 96 not supported
r_reg_get_value: Bit size 96 not supported
r_reg_get_value: Bit size 96 not supported
r_reg_get_value: Bit size 96 not supported
r_reg_get_value: Bit size 96 not supported
r_reg_get_value: Bit size 96 not supported
r_reg_get_value: Bit size 96 not supported
r_reg_get_value: Bit size 96 not supported
r_reg_get_value: Bit size 96 not supported
READ 0xeaffff00 4
READ 0x26090 4
READ 0xfffe8d94 4
READ 0xe59f0004 4
READ 0xe08f0000 4
READ 0xe12fff1e 4
READ 0x268f4 4
READ 0xe5903004 4
READ 0xe2833001 4
READ 0xe5803004 4
READ 0xe12fff1e 4
READ 0xe5903004 4
READ 0xb6fd8f20 63
r_reg_get_value: Bit size 96 not supported
r_reg_get_value: Bit size 96 not supported
r_reg_get_value: Bit size 96 not supported
r_reg_get_value: Bit size 96 not supported
r_reg_get_value: Bit size 96 not supported
r_reg_get_value: Bit size 96 not supported
r_reg_get_value: Bit size 96 not supported
r_reg_get_value: Bit size 96 not supported
r_reg_get_value: Bit size 96 not supported
READ 0xfffe8d94 4
READ 0xe59f0004 4
READ 0xe08f0000 4
READ 0xe12fff1e 4
READ 0x268f4 4
READ 0xe5903004 4
READ 0xe2833001 4
READ 0xe5803004 4
READ 0xe12fff1e 4
READ 0xe5903004 4
READ 0xe2433001 4
READ 0xe5803004 4
           ;-- r15:
           0xb6fd8e80    90909fe5     ldr sb, [pc, 0x90] ; [0xb6fd8f18:4]=0xeaffffe4
           0xb6fd8e84    94409fe5     ldr r4, [pc, 0x94] ; [0xb6fd8f20:4]=0x93c
READ 0xb6fd8e80 256
r_debug_gdb_reg_read: small buffer 176 vs 200

pd/pi speed test:

[0xb6fd8e80]> ?t pi 10
0.000435
[0xb6fd8e80]> ?t pd 10
11.380791

[radare]

Pushed an optimization for the slow pd problem in 6e3d16dc814cab4c3563ed495e6dcb49d86d1227

[pleonex]

Hi, I am trying to migrate from IDA Pro to radare2 for Nintendo DS debugging (ARMv5/ARM9 processor). I am using DeSmuME emulator that supports GDB remote debugging and after increasing its buffer size I made it to work but found these issues.

Looking into the emulator sources I figure out why it's giving r_reg_get_value: Bit size 96 not supported warning. In source value.c it converts the bytes into a register value, it seems that in arm platforms, there are [8 registers]() for float numbers with 96 bits length.

I will continue looking into other warnings and performance issues (each stepIn in visual mode takes 13 seconds).

[radare]

debugging is slow in some platforms (windows, gdb remote, ..) because those targets takes so much time to read memory and registers and list maps.

this is a known issue that must be addressed before next release. because the frontend is performing too much unnecessary calls to those resources.. so its fine for local linux and osx, but the rest are really slow. This can be easily catched by using callgrind and then visualizing the results with kcachegrind, or by placing some printfs (or breakpoints) in the io and debug plugins.

its good to know that stepping works :P

On 10 Aug 2015, at 10:41, Benito Palacios Sánchez notifications@github.com wrote:

Hi, I am trying to migrate from IDA Pro to radare2 for Nintendo DS debugging (ARMv5/ARM9 processor). I am using DeSmuME http://sourceforge.net/projects/desmume/ emulator that supports GDB remote debugging and after increasing its buffer size I made it to work but found these issues.

Looking into the emulator sources http://sourceforge.net/p/desmume/code/HEAD/tree/trunk/desmume/src/gdbstub/gdbstub.cpp#l934 I figure out why it's giving r_reg_get_value: Bit size 96 not supported warning. In source value.c https://github.com/radare/radare2/blob/acd2ab9cb5925fef8405a3f6de2a85a05089811c/libr/reg/value.c#L111 it converts the bytes into a register value, it seems that in arm platforms, there are 8 registers applewebdata://C4C4E665-4362-42A0-A1C9-FDCA5AF224C8 for float numbers with 96 bits length.

I will continue looking into other warnings and performance issues (each stepIn in visual mode takes 13 seconds).

— Reply to this email directly or view it on GitHub https://github.com/radare/radare2/issues/1773#issuecomment-129367422.

[radare]

@pleonex feel free to join the irc for further discussions

[XVilka]

@radare @SrimantaBarua probably not reproducible anymore?

[SrimantaBarua]

qemu-system-arm works, as per my tests. I don't have an rpi to test on :/

The speed has probably been improved by no-ack mode, reg caching, and increasing packet size. It will increase more by mem caching, which is slightly more complicated.

So I think this can be closed. @radare , comments?

[radare]

i would like to test it before closing. thanks!

[radare]

Confirmed with gdbserver running on Termux on ARM64. Good work!