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.