Re: read target register to decide breakpoint size

[Tim Newsome <tim@sifive.com>]

I finally got around to implementing this, but gdb still insists on
calling breakpoint_kind_from_pc, where I don't have access to a
regcache object (I think). Eg.
```
#0  riscv_breakpoint_kind_from_pc (gdbarch=0xcc8a90,
pcptr=0x7fffffffde68) at riscv-tdep.c:184
#1  0x0000000000541301 in default_breakpoint_from_pc
(gdbarch=0xcc8a90, pcptr=<optimized out>, lenptr=0x7fffffffde64)
    at arch-utils.c:847
#2  0x00000000004b40b3 in program_breakpoint_here_p
(gdbarch=<optimized out>, address=2147550320) at breakpoint.c:9113
#3  0x00000000004b424c in bp_loc_is_permanent (loc=0xdd57b0) at
breakpoint.c:9156
#4  add_location_to_breakpoint (b=b@entry=0xda9aa0,
sal=sal@entry=0x7fffffffdf70) at breakpoint.c:9093
#5  0x00000000004b5169 in init_raw_breakpoint (ops=0xb4d200
<bkpt_breakpoint_ops>, bptype=bp_breakpoint, sal=...,
    gdbarch=0xcc8a90, b=0xda9aa0) at breakpoint.c:7586
#6  init_breakpoint_sal (b=b@entry=0xda9aa0,
gdbarch=gdbarch@entry=0xcc8a90, location=location@entry=0xda8f30,
    filter=filter@entry=0x0, cond_string=0x0, extra_string=0x0,
type=bp_breakpoint, disposition=disp_donttouch,
    thread=-1, task=0, ignore_count=0, ops=0xb4d200
<bkpt_breakpoint_ops>, from_tty=1, enabled=1, flags=0,
    display_canonical=0, internal=<optimized out>, sals=...) at
breakpoint.c:9300
#7  0x00000000004bb490 in create_breakpoint_sal (display_canonical=0,
flags=0, internal=0, enabled=1, from_tty=1,
    ops=0xb4d200 <bkpt_breakpoint_ops>, ignore_count=0, task=0,
thread=-1, disposition=disp_donttouch,
    type=bp_breakpoint, extra_string=0x0, cond_string=0x0, filter=0x0,
location=0xda8f30, gdbarch=0xcc8a90, sals=...)
    at breakpoint.c:9436
#8  create_breakpoints_sal (gdbarch=0xcc8a90,
canonical=0x7fffffffe170, cond_string=0x0, extra_string=0x0,
    type=bp_breakpoint, disposition=disp_donttouch, thread=-1, task=0,
ignore_count=0,
    ops=0xb4d200 <bkpt_breakpoint_ops>, from_tty=1, enabled=1,
internal=0, flags=0) at breakpoint.c:9490
#9  0x00000000004bbbfc in create_breakpoint (gdbarch=0xcc8a90,
location=location@entry=0xda3af0,
    cond_string=cond_string@entry=0x0, thread=-1, thread@entry=0,
extra_string=<optimized out>,
    extra_string@entry=0xda3ad6 "", parse_extra=parse_extra@entry=1,
tempflag=0, type_wanted=bp_breakpoint,
    ignore_count=0, pending_break_support=AUTO_BOOLEAN_AUTO,
ops=0xb4d200 <bkpt_breakpoint_ops>, from_tty=1, enabled=1,
    internal=0, flags=0) at breakpoint.c:9912
#10 0x00000000004bc099 in break_command_1 (arg=0xda3ad6 "",
flag=<optimized out>, from_tty=1) at breakpoint.c:10020
...
```

Is there some way I can check the misa register of my target from
default_breakpoint_from_pc, or have gdb not call
default_breakpoint_from_pc and use breakpoint_kind_from_current_state
instead?

Thank you,
Tim

On Mon, Nov 21, 2016 at 10:00 AM, Tim Newsome <tim@sifive.com> wrote:
> Thanks, Antoine! That's exactly what I was looking for.
>
> Tim
>
> On Mon, Nov 21, 2016 at 8:36 AM, Antoine Tremblay
> <antoine.tremblay@ericsson.com> 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