New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enhace/Fix issues in the GDB backend (ARM on RPI) #1773
Comments
Some debugging of why 'pd' is slow. Also, i have verified that plain 'pi' is fast.
pd/pi speed test:
|
Pushed an optimization for the slow |
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 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
|
@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 VERY_SLOW (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)
The text was updated successfully, but these errors were encountered: