Re: read target register to decide breakpoint size

Tim Newsome <[email protected]>
Newsgroups gmane.comp.gdb.devel
Message-ID <CAGDihe=cyG646+D1POAaBSiWYAxH_ap+C0j=+hxVBdZq1N0LBA@mail.gmail.com>
Thanks, Antoine! That's exactly what I was looking for.

Tim

On Mon, Nov 21, 2016 at 8:36 AM, Antoine Tremblay
<[email protected]> wrote:
>
>
> Tim Newsome writes:
>
> > 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?
>
> Yes actually you can check how ARM does it, it has the same kind of
> problem with 3 breakpoints you can set for thumb, thumb2 and arm
> instruction sets.
>
> See arm-tdep.c:arm_sw_breakpoint_from_kind and
> arm_breakpoint_kind_from_current_state
>
> This is called in breakpoint.c:breakpoint_kind and it can use a register
> to make the decision from the current state of that register.
>
> So possibly just implementing the sw_breakpoint_from_kind and
> breakpoint_kind_from_current state would be ok your you.
>
> Regards,
> Antoine Tremblay
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.