-
Notifications
You must be signed in to change notification settings - Fork 257
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
GDB 7.10 from NDK r11b returns inconsistent MI result record for -exec-step command #60
Comments
The |
Try gdb 7.11 from the r12 beta, we've had internal reports of single stepping being broken with 7.10 that were resolved with 7.11. |
Is this fixed? |
Re-open if this is still present in r12. |
I'm debugging UE4 demo with GDB 7.10 from NDK R11B for Windows 64-bit connected to AARCH64 API23 target.
Sometimes, GDB responds with seemingly incorrect async MI result record after the target's execution is resumed by
-exec-step
command.According to GDB MI documentation and GDB test suite I expect that in this case the MI result record should always contain a reason field:
*stopped,reason="end-stepping-range"
This is also baked by changelog note
2009-02-14 Vladimir Prus [email protected]
* lib/mi-support.exp (mi_expect_stop): Adjust the order of fields.
(mi_expect_interrupt): Likewise.
* gdb.mi/mi-cli.exp: Check that "step" results in proper *stopped
response.
and test cases defined in
binutils-gdb/gdb/testsuite/gdb.mi/mi-cli.exp
This stop without a reason behavior is irritating, because it doesn't fit into expected response pattern. Should the front-end treat a step request as successfully completed after receiving this notification record? This inconsistency requires additional and unnecessary decision-making logic on the front-end.
The text was updated successfully, but these errors were encountered: