Simple example:
https://asciinema.org/a/88v8zgh60xedoz4htc34hfhq2
Also tried with "dbc 0x4028aa wx deadbeef @ rdx" and it's left unchanged.
this is : “breakpoint commands are not executed”
On 20 Jun 2016, at 17:52, monosource [email protected] wrote:
Simple example:
https://asciinema.org/a/88v8zgh60xedoz4htc34hfhq2 https://asciinema.org/a/88v8zgh60xedoz4htc34hfhq2
Also tried with "dbc 0x4028aa wx deadbeef @ rdx" and it's left unchanged.—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/radare/radare2/issues/5182, or mute the thread https://github.com/notifications/unsubscribe/AA3-lpgAGmxqLSD0AVMxfk9J8sXW30gNks5qNrdYgaJpZM4I52FN.
FWIW the simple test I added passes on both Linux (without issue) and OSX (after jumping through some signing/password prompt hoops). I'll add a more sophisticated test.
@monosource The problem is that the registers are not synchronized before executing these commands. Try setting cmd.bp to .dr* or prepending .dr*; to your *rdx=0xdeadbeef like this:
"dbc <addr> .dr*;*rdx=0xdeadbeef"
@jduck Interesting; indeed, the values seem to be lost somewhere in the code, and .dr* forces them back in place. But I think the result of the dbc commands should be identical to the result of running them manually when reaching that breakpoint.
Found another bug, this time in loops: "dbc <addr> dr eax". eax is not listed (or only listed at the end of the loop).
I agree with you. The thing is that currently the prompt command is changed when you activate the debugger. That is where the registers and so on are synchronized. I think this is not a workable solution and so I will hopefully be able to get things in better shape soon.
IMHO the prompt command is overkill for synchronizing such things. Think about it. If you hit a breakpoint and then execute several commands, is it really necessary to sync everything after every command??
I'm not sure about the loop issue. Can you put together a test script like the one linked above?
Yep i know its suboptimal. But it was enough for my needs and was working properly. I use to develop doing iterations because its hard to understand all the problems you may face when implementing somwthing that needs to work on severa platforms and feature requests that are growing every day :)
So any enhancement is welcome here
On 21 Jun 2016, at 17:45, Joshua J. Drake [email protected] wrote:
I agree with you. The thing is that currently the prompt command is changed when you activate the debugger. That is where the registers and so on are synchronized. I think this is not a workable solution and so I will hopefully be able to get things in better shape soon.
IMHO the prompt command is overkill for synchronizing such things. Think about it. If you hit a breakpoint and then execute several commands, is it really necessary to sync everything after every command??
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
@jduck https://asciinema.org/a/bh6njbp1yerpp1bc2hdw0em44 loop issue.
It seems to be related to using sequenced commands in conjunction with dbc.
@monosource there is a loop program in radare2-regressions you can use to make the test. The compiled binary is in bins/elf/x64-loop ...
I think the root cause of this issue is "registers are not synchronized before executing breakpoint commands". Registers should be synchronized whenever the inferior stops and then kept up-to-date whenever any commands that change them are used. I'd like to introduce a "cmd.dbgstop" command to allow users to set commands to be executed on stop, but this is not sufficient for handling breakpoint commands or via the r_debug API.
Tracking the stop commands thing as https://github.com/radare/radare2/issues/5264 and this issue should become "registers not synchronized before executing breakpoint commands".
This issue has been automatically marked as stale because it has not had recent activity. Considering a lot has changed since its creation, we kindly ask you to check again if the issue you reported is still relevant in the current version of radare2. If it is, update this issue with a comment, otherwise it will be automatically closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically closed because marked as stale and it has not been updated since then. If the issue is still relevant, feel free to re-open it or open a new one.