Closed radare closed 7 years ago
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
Pushed an optimization for the slow pd
problem in 6e3d16dc814cab4c3563ed495e6dcb49d86d1227
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).
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.
@pleonex feel free to join the irc for further discussions
@radare @SrimantaBarua probably not reproducible anymore?
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?
i would like to test it before closing. thanks!
Confirmed with gdbserver running on Termux on ARM64. Good work!
Those are some of the issues I have found debugging a remote gdbserver on RPI with r2:
Also, the IO is _VERYSLOW (disassembling 2 instructions takes 7 seconds:
This slowdown is probably because of the lack of memoization or caching. The speed for plain reads with p8 is quite better:
Setting values to registers doesn't works:
buf if you show ALL the regs:
Reading and writing memory seems to work fine, (reading speed must be improved)