This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug gdb/18003] New: Some fails in gdb.base/breakpoint-in-ro-region.exp
- From: "qiyao at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Fri, 20 Feb 2015 12:27:18 +0000
- Subject: [Bug gdb/18003] New: Some fails in gdb.base/breakpoint-in-ro-region.exp
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=18003
Bug ID: 18003
Summary: Some fails in gdb.base/breakpoint-in-ro-region.exp
Product: gdb
Version: HEAD
Status: NEW
Severity: normal
Priority: P2
Component: gdb
Assignee: unassigned at sourceware dot org
Reporter: qiyao at gcc dot gnu.org
I see some fails as below on aarch64-linux-gnu target, in both remote and
native testing...
si^M
0x0000000000400738 23 i = 0;^M
(gdb) FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw
off: step in ro region
si^M
0x0000000000400740 24 i = 0;^M
(gdb) FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw
off: step in ro region
looks the hex is unexpected to the pattern matching,
set test "step in ro region"
gdb_test_multiple "si" $test {
-re "Could not insert hardware breakpoints.*$gdb_prompt $" {
gdb_assert {!$hw_step && $auto_hw == "on" && !$supports_hbreak} \
"$test (cannot insert hw break)"
}
-re "Cannot set software breakpoint at read-only address
$next_insn.*$gdb_prompt $" {
gdb_assert {!$hw_step && $auto_hw == "off"} \
"$test (cannot insert sw break)"
}
-re "^si\r\nNote: automatically using hardware breakpoints for read-only
addresses\.\r\n${decimal}\[ \t\]+i = 0;\r\n$gdb_prompt $" {
gdb_assert {!$hw_step && $auto_hw == "on" && $supports_hbreak} \
"$test (auto-hw)"
}
-re "^si\r\n${decimal}\[ \t\]+i = 0;\r\n$gdb_prompt $" {
gdb_assert {$hw_step || ($auto_hw == "on" && $supports_hbreak)} \
"$test (no error)"
}
}
further analysis is needed.
--
You are receiving this mail because:
You are on the CC list for the bug.