This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug gdb/16101] New: gdb.base/dprintf.exp agent-printf failures with non-Z0-supporting gdbservers
- From: "macro at linux-mips dot org" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Wed, 30 Oct 2013 19:07:37 +0000
- Subject: [Bug gdb/16101] New: gdb.base/dprintf.exp agent-printf failures with non-Z0-supporting gdbservers
- Auto-submitted: auto-generated
http://sourceware.org/bugzilla/show_bug.cgi?id=16101
Bug ID: 16101
Summary: gdb.base/dprintf.exp agent-printf failures with
non-Z0-supporting gdbservers
Product: gdb
Version: HEAD
Status: NEW
Severity: normal
Priority: P2
Component: gdb
Assignee: unassigned at sourceware dot org
Reporter: macro@linux-mips.org
Target: arm-linux-gnueabi, mips-linux-gnu, powerpc-linux-gnu
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.
--
You are receiving this mail because:
You are on the CC list for the bug.