There is an issue with agent dprintf on targets where `gdbserver' does not support the `Z0' packet. There GDB inserts software breakpoints itself, by poking at memory explicitly to modify the instruction stream. This includes dprintf breakpoints. Once such a breakpoint has hit `gdbserver' reports the hit to GDB (without executing the dprintf request). GDB in turn sees `agent-printf' in the list of breakpoint commands and complains: May only run agent-printf on the target This is observed in GDB testing: FAIL: gdb.base/dprintf.exp: 1st dprintf, agent FAIL: gdb.base/dprintf.exp: 2nd dprintf, agent on at least the arm-linux-gnueabi, mips-linux-gnu and powerpc-linux-gnu targets. I think it would be consistent if agent dprintf was not allowed for GDB breakpoints. However disabling the breakpoint commands feature on such targets altogether would regress hardware (`Z1') breakpoints where supported, so it looks to me that agent dprintf should be a per-breakpoint feature, resorting to one of the other styles (probably gdb) for GDB breakpoints.
See: https://sourceware.org/ml/gdb-patches/2013-10/msg00615.html
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "gdb and binutils". The branch, master has been updated via 0000e5ccd8615d632ac6ddc831cd5d3af8084737 (commit) from c66a241cde1b8fe4207d425c9956cb6dac948732 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=0000e5ccd8615d632ac6ddc831cd5d3af8084737 commit 0000e5ccd8615d632ac6ddc831cd5d3af8084737 Author: Pedro Alves <palves@redhat.com> Date: Thu Jan 9 18:33:45 2014 +0000 Handle the case of a remote target supporting target side commands, but not on software breakpoints. Although we can tell upfront whether a remote target supports target side commands, we can only tell whether the target supports that in combination with a given breakpoint kind (software, hardware, watchpoints, etc.) when we go and try to insert such a breakpoint kind the first time. It's not desirable to make remote_insert_breakpoint simply return -1 in this case, because if the breakpoint was set in a shared library, insert_bp_location will assume that the breakpoint insertion failed because the library wasn't mapped in. insert_bp_location already handles errors/exceptions thrown from the target_insert_xxx methods, exactly so the backend can tell the user the detailed reason the insertion of hw breakpoints failed. But, in the case of software breakpoints, it discards the detailed error message. So the patch makes insert_bp_location use the error's message for SW breakpoints too, and, introduces a NOT_SUPPORTED_ERROR error code so that insert_bp_location doesn't confuse the error for failure due to a shared library disappearing. The result is: (gdb) c Warning: Cannot insert breakpoint 2: Target doesn't support breakpoints that have target side commands. 2014-01-09 Pedro Alves <palves@redhat.com> Hui Zhu <hui@codesourcery.com> PR gdb/16101 * breakpoint.c (insert_bp_location): Rename hw_bp_err_string to bp_err_string. Don't mark the location shlib_disabled if the error thrown wasn't a generic or memory error. Catch errors thrown while inserting breakpoints in overlayed code. Output error message of software breakpoints. * remote.c (remote_insert_breakpoint): If this breakpoint has target-side commands but this stub doesn't support Z0 packets, throw NOT_SUPPORTED_ERROR error. * exceptions.h (enum errors) <NOT_SUPPORTED_ERROR>: New error. * target.h (target_insert_breakpoint): Extend comment. (target_insert_hw_breakpoint): Add comment. ----------------------------------------------------------------------- Summary of changes: gdb/ChangeLog | 16 ++++++++ gdb/breakpoint.c | 105 +++++++++++++++++++++++++++++++++++++++-------------- gdb/exceptions.h | 3 ++ gdb/remote.c | 6 +++ gdb/target.h | 11 +++++- 5 files changed, 111 insertions(+), 30 deletions(-)
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "gdb and binutils". The branch, master has been updated via 88bbeca9d5e9429dbd2a11d754f24d649b8e5488 (commit) from d23487918b315cccd04c2b60a7cf7775920caecb (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=88bbeca9d5e9429dbd2a11d754f24d649b8e5488 commit 88bbeca9d5e9429dbd2a11d754f24d649b8e5488 Author: Hui Zhu <hui@codesourcery.com> Date: Mon Mar 24 19:30:50 2014 +0000 Fix PR breakpoints/16101: gdb.base/dprintf.exp agent-printf failures with non-Z0-supporting gdbservers After a previous patch that was committed by Pedro (0000e5cc), trying to set a dprintf with with a GDBserver that doesn't support agent commands at all now throws an error. But the dprintf tests still fail with some GDBserver targets because they doesn't try to handle the case of the server reporting support for breakpoint commands, but not be able to use those in combination with Z0 (because Z0 isn't actually supported, for example): FAIL: gdb.base/dprintf.exp: 1st dprintf, agent FAIL: gdb.base/dprintf.exp: 2nd dprintf, agent FAIL: gdb.base/dprintf.exp: dprintf info 2 (pattern 4) Similarly for the MI test. This patch makes the tests handle this scenario. Tested with native, and native gdbserver on x86_64 Fedora 17. Also tested with the native-gdbserver.exp board hacked with: set GDBFLAGS "${GDBFLAGS} -ex \"set remote breakpoint-commands off\"" (actually, "set remote breakpoint-commands off" is presently broken, so this was on top of a fix for that command.) which results in: (gdb) PASS: gdb.base/dprintf.exp: 2nd dprintf, gdb set dprintf-style agent warning: Target cannot run dprintf commands, falling back to GDB printf warning: Target cannot run dprintf commands, falling back to GDB printf (gdb) UNSUPPORTED: gdb.base/dprintf.exp: set dprintf style to agent gdb.sum: Running target native-gdbserver Running ../../../src/gdb/testsuite/gdb.base/dprintf.exp ... PASS: gdb.base/dprintf.exp: dprintf PASS: gdb.base/dprintf.exp: dprintf foo PASS: gdb.base/dprintf.exp: dprintf 29 PASS: gdb.base/dprintf.exp: dprintf foo,"At foo entry\n" PASS: gdb.base/dprintf.exp: ignore $bpnum 1 PASS: gdb.base/dprintf.exp: dprintf 26,"arg=%d, g=%d\n", arg, g PASS: gdb.base/dprintf.exp: dprintf info 1 PASS: gdb.base/dprintf.exp: break 27 PASS: gdb.base/dprintf.exp: 1st dprintf, gdb PASS: gdb.base/dprintf.exp: 2nd dprintf, gdb UNSUPPORTED: gdb.base/dprintf.exp: set dprintf style to agent PASS: gdb.base/dprintf.exp: Set dprintf style to an unrecognized type And also with the native-gdbserver.exp board hacked with: set GDBFLAGS "${GDBFLAGS} -ex \"set remote Z-packet off\"" which results in: (gdb) continue Continuing. Warning: Cannot insert breakpoint 3: Target doesn't support breakpoints that have target side commands. Cannot insert breakpoint 4: Target doesn't support breakpoints that have target side commands. (gdb) UNSUPPORTED: gdb.base/dprintf.exp: 1st dprintf, agent gdb.sum: Running target native-gdbserver Running ../../../src/gdb/testsuite/gdb.base/dprintf.exp ... PASS: gdb.base/dprintf.exp: dprintf PASS: gdb.base/dprintf.exp: dprintf foo PASS: gdb.base/dprintf.exp: dprintf 29 PASS: gdb.base/dprintf.exp: dprintf foo,"At foo entry\n" PASS: gdb.base/dprintf.exp: ignore $bpnum 1 PASS: gdb.base/dprintf.exp: dprintf 26,"arg=%d, g=%d\n", arg, g PASS: gdb.base/dprintf.exp: dprintf info 1 PASS: gdb.base/dprintf.exp: break 27 PASS: gdb.base/dprintf.exp: 1st dprintf, gdb PASS: gdb.base/dprintf.exp: 2nd dprintf, gdb PASS: gdb.base/dprintf.exp: set dprintf style to agent UNSUPPORTED: gdb.base/dprintf.exp: 1st dprintf, agent PASS: gdb.base/dprintf.exp: Set dprintf style to an unrecognized type (One of the new comments mentions breakpoint always-inserted mode. Actually testing with breakpoint always-inserted mode fails these dprintf tests, due to the way they are written. But that'll take a more substancial rewrite of the tests, so I'm leaving that for another day.) gdb/testsuite/ 2014-03-24 Hui Zhu <hui@codesourcery.com> Pedro Alves <palves@redhat.com> PR breakpoints/16101 * gdb.base/dprintf.exp: Use unsupported rather than changing the test pass/fail messages. Detect missing support for dprintf when breakpoints are actually inserted. * gdb.base/mi-dprintf.exp: Detect missing support for dprintf when breakpoints are actually inserted. * lib/mi-support.exp (mi_run_cmd_full): Return -1 if continue fails. ----------------------------------------------------------------------- Summary of changes: gdb/testsuite/ChangeLog | 12 ++++++++ gdb/testsuite/gdb.base/dprintf.exp | 53 ++++++++++++++++++++++++---------- gdb/testsuite/gdb.mi/mi-dprintf.exp | 45 ++++++++++++++++++------------ gdb/testsuite/lib/mi-support.exp | 1 + 4 files changed, 77 insertions(+), 34 deletions(-)
Fixed.