Some testsuite cases (gdb.cp/nsalias.exp for example) construct dwarf2
debug info for fake functions to test that this debug info is handled
correctly.
We currently get an error trying to read from an invalid address while
creating breakpoints for these fake functions.
Other targets allow creating breakpoints on invalid addresses, and
only error when GDB actually tries to insert the breakpoints.
In order to make RISC-V behave in the same way as other targets, this
commit makes the failure to read memory during breakpoint creation
non-fatal, we then expect to see a failure when GDB tries to insert
the breakpoint, just like other targets.
Tested with a riscv64-linux native testsuite run.
gdb/ChangeLog:
* riscv-tdep.c (riscv_breakpoint_kind_from_pc): Hanndle case where
code read might fail, assume 4-byte breakpoint in that case.
+2019-04-17 Jim Wilson <jimw@sifive.com>
+ Andrew Burgess <andrew.burgess@embecosm.com>
+
+ * riscv-tdep.c (riscv_breakpoint_kind_from_pc): Hanndle case where
+ code read might fail, assume 4-byte breakpoint in that case.
+
2019-04-15 Leszek Swirski <leszeks@google.com>
* amd64-tdep.c (amd64_classify_aggregate): Use cp_pass_by_reference
unaligned_p = true;
else
{
- /* Read the opcode byte to determine the instruction length. */
+ /* Read the opcode byte to determine the instruction length. If
+ the read fails this may be because we tried to set the
+ breakpoint at an invalid address, in this case we provide a
+ fake result which will give a breakpoint length of 4.
+ Hopefully when we try to actually insert the breakpoint we
+ will see a failure then too which will be reported to the
+ user. */
+ if (target_read_code (*pcptr, buf, 1) == -1)
+ buf[0] = 0;
read_code (*pcptr, buf, 1);
}