-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Wrong debugging execution after a "ldrls" instruction (ARM) #3893
Comments
Btw, I have noticed that the Visual (Vpp) mode has a incorrect register in order to show the stack. r2 used the r14 register to show the stack instead the r13 register:
|
Thanks! i have fixed that R13 issue, it was only happening in some debugger backends. it was ok for iOS for example.. nice catch! |
The ESIL expression for that
|
I don't know much the r2 source code, but when I have some time I am going to try to create a PR ;) Thanks!! |
Its just editing the libr/anal/p/anal_arm_cs.c to change the expression that is generated for that instruction. But i dont see a reason why this should fail when debugging. Esil will fix the emulation only. |
ESIL seems that is working properly. This is my code:
ESIL says that PC will be "0xcde0", so it is right, isn't it? |
The problem could be into "libr/bp/bp.c". When a single step "ds" is done, this function try to add the breakpoint in "0xcdc4", so the next address is not calculated properly. In the "r_bp_get_in" function it can be seen the next address:
On the other hand, I have noticed that when a breakpoint is set and we are in the bp address, the "ds" command returns:
Here is the "r_bp_get_in" variables
Due to "(b->addr+b->size) = addr" the function does not allow add a new bp in order to continue with the execution. If instead of "ds" command we type the "dso" command a bp is set an we can continue with the execution. Maybe the "addr <= (b->addr+b->size)" should be changed by "addr < (b->addr+b->size)"? |
Stepping shouldnt be using breakpoints on arm for linux because there's already hardware support for it. So you can check the value of dbg.swstep, it should be set to false. But the breakpoint thing is a bug indeed. About the esil expression, check the expression instead of the final value, i have the impression that this is only working for some cases. Didnt had much time to check it out. Im afk right now. Thx
|
The ESIL expression for now: should be: |
I have pushed a fix for the ESIL expression thing, but it turns out that it happens because of a bug in capstone. So i can't retrieve the value of the |
Found the way capstone handles the shift in there and fixed the test and ESIL implementation. i'll look into the breakpoint issue later |
Should be fixed now. Please confirm :) |
r2 is not debugging the execution properly after a "ldrls" instruction.
The text was updated successfully, but these errors were encountered: