Re: read target register to decide breakpoint size

[Ofir Cohen <ofircohenn@gmail.com>]

Hi,
I've been messing with that code lately,
and I recall gdb is checking if the instruction is a breakpoint instruction
in validate_inserted_breakpoint() function:

if (err || memcmp (buf, bp_opcode (bp), bp_size (bp)) != 0)

Also, you should check out breakpoint_from_pc callback function (IIRC
implemented in target_ops), from [1]:
"breakpoint_from_pc. Returns the breakpoint instruction to be used
when the PC is at a
particular location in memory. For architectures with variable length
instructions, the
choice of breakpoint instruction may depend on the length of the
instruction at the
program counter. Returns the instruction sequence and its length.
The default value is NULL (undefined). This function should always be
defined if GDB is
to support breakpointing for this architecture."

So IOW gdb is (somewhat) flexible when it comes to determining
instruction breakpoints.

You should probably initialize the breakpoint size (2/4) at target
init stage, cache it within your module and return at runtime the
(correct) cached size.

Guys on the mailing list can probably elabore more on this, but hey
this is a place to start :-).

Good luck.

Regards,
Ofir Cohen

[1] http://www.embecosm.com/appnotes/ean3/embecosm-howto-gdb-porting-ean3-issue-2.pdf

On 19 November 2016 at 01:44, Tim Newsome <tim@sifive.com> wrote:
> I'm still working on RISC-V support for gdb. Any given RISC-V core may
> support a compressed instruction set (2 bytes per instruction as
> opposed to 4). There are corresponding 2-byte and 4-byte breakpoint
> instructions. On cores that support the compressed instruction set it
> is safe to just always use the 2-byte version, and there is a register
> I can read to tell me whether the compressed instruction set is
> supported. What I would like to do is read (and cache) that register
> when breakpoint size is determined. That seems more robust than making
> a decision based on ELF info, which may not reflect what is actually
> being executed.
>
> Is that a good idea? Are there examples of operations that read target
> registers to complete?
>
> Thank you,
> Tim