Re: gdb for Riscv, single stepping issue

Pedro Alves <[email protected]>
Newsgroups gmane.comp.gdb.devel
Message-ID <[email protected]>
Hi!

Jim, could you check whether the patch below addresses the issue for you?
I imagine it does, but it'd be good to hear just in case we're missing some
more target_read_memory calls somewhere or some such.

Pedro Alves

On 2022-06-29 18:54, John Baldwin wrote:
> On 6/29/22 2:34 AM, Pedro Alves wrote:

>> OTOH, riscv_insn::fetch_instruction uses target_read_memory to read 2 bytes,
>> so I wonder whether this is the access in question:
>>
>>    /* All insns are at least 16 bits.  */
>>    status = target_read_memory (addr, buf, 2);
>>    if (status)
>>      memory_error (TARGET_XFER_E_IO, addr);
>>
>> Why is this using target_read_memory instead of target_read_code, though?
>> If it did that, then the code cache would be involved here too, papering over
>> the issue, presumably.
>>
> Yes, I had reworked my e-mail part way through and I really meant to talk about
> this code, not the breakpoint code.  I agree that target_read_code is probably
> more correct in fetch_instruction and would in this case hide the odd behavior
> of the stub:
> 
> diff --git a/gdb/riscv-tdep.c b/gdb/riscv-tdep.c
> index 69f2123dcdb..09b2599e958 100644
> --- a/gdb/riscv-tdep.c
> +++ b/gdb/riscv-tdep.c
> @@ -1661,7 +1661,7 @@ riscv_insn::fetch_instruction (struct gdbarch *gdbarch,
>    int instlen, status;
>  
>    /* All insns are at least 16 bits.  */
> -  status = target_read_memory (addr, buf, 2);
> +  status = target_read_code (addr, buf, 2);
>    if (status)
>      memory_error (TARGET_XFER_E_IO, addr);
>  
> @@ -1672,7 +1672,7 @@ riscv_insn::fetch_instruction (struct gdbarch *gdbarch,
>  
>    if (instlen > 2)
>      {
> -      status = target_read_memory (addr + 2, buf + 2, instlen - 2);
> +      status = target_read_code (addr + 2, buf + 2, instlen - 2);
>        if (status)
>      memory_error (TARGET_XFER_E_IO, addr + 2);
>      }
> 
>
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.