Re: read target register to decide breakpoint size

[Tim Newsome <tim@sifive.com>]

On Wed, Dec 14, 2016 at 4:32 AM, Antoine Tremblay
<antoine.tremblay@ericsson.com> wrote:
>
> Yao Qi writes:
>
>> On 16-12-13 13:30:02, Tim Newsome wrote:
>>> Actually, this seems to work inside breakpoint_kind_from_pc():
>>> ```
>>>     struct frame_info *frame = get_current_frame ();
>>>     uint32_t misa = get_frame_register_unsigned (frame, RISCV_CSR_MISA_REGNUM);
>>> ```
>>>
>>> Is that kosher? If so, is there any reason for me to implement
>>> breakpoint_kind_from_current_state?
>>
>> I'd like not to do so.  Can't you decode the instruction to see whether
>> it is compressed or uncompressed?  I also think it is a good idea to
>> make a decision based on ELF info, as you mentioned in the first email.
>
> Correct me if I'm wrong but reading the RISC-V arch manual, it seems
> like the MISA register information is static.
>
> So unlike arm where the ISA might change, on RISC-V it is static for the
> life of the program ?

That's right. MISA doesn't ever change.

> If that's true, and that you can't decode the instruction, it doesn't
> seem that bad to use the register in kind_from_pc ?

I could take a stab at decoding the instruction, but that seems a lot
more painful.
1. It's more code to write.
2. RISC-V encourages people adding custom instructions, which gdb
shouldn't have to know about.
3. Decoding the instruction might force a memory read, which is slow.
I only need to read MISA once.

> Yao, was your concern that this would be non-static, or there is another
> reason ?
>
> However thinking about the ELF info, could you elaborate on why it may
> not reflect what is actually being executed ? And how this is a problem
> ?

In the simplest case, I can connect to my target using OpenOCD, and
not tell gdb what file is being executed. It should still be possible
to debug at the assembly level in that case.

> A note about _from_current_state too this is used while single_stepping
> since GDB knows it's about to set a breakpoint from a known state to
> the next location, this differs from from_pc which is used to set a pc from
> any state to any location.
>
> So in your case it's really from_pc that you want.

I see. So that's a case for ARM where it could look at cpsr.

Thank you, sounds like reading MISA from kind_from_pc should work out
fine then (unless Yao has an objection we didn't consider).

Tim