Enable riscv virt2phys_mode to hw, insert breakpoing failed.

[weiqi7777]

hi:
we use the hardware translate virtual address to access memory.
as below:

when we execute si command in gdb, it print the warning, and gdb will not work after the warning.

We reproduced this scenario on the hardware and found that OpenOCD made the hardware modify the instruction region by walking the page table and inserting ebreak instructions. However, this instruction region's page table attributes lack the Write (W) permission, causing the write operation to fail.

So how should we solve the warning?

thanks

[TommyMurphyTM1234]

So how should we solve the warning?

Use hardware breakpoints for the non-writeable area of memory? As one would normally do with other non-writeable memory regions such as flash?

[weiqi7777]

The memory is instruction region, the attribute page of the memory is x, so write is forbidden.
But the GDB will insert the ebreak instruction into the instruction region, and use hardware translate the virtual address to physical address to write it. It is not working.

[TommyMurphyTM1234]

So try using hardware breakpoints instead as I already suggested?

• https://sourceware.org/gdb/current/onlinedocs/gdb.html/Set-Breaks.html

If necessary, mark the memory region as (executable) read-only in GDB so that it should automatically use hardware instead of software breakpoints:

• https://sourceware.org/gdb/current/onlinedocs/gdb.html/Memory-Region-Attributes.html

Hardware breakpoints are described in the OpenOCD documentation:

• https://openocd.org/doc/html/General-Commands.html

[aap-sc]

@weiqi7777 do I understand correctly that if hw virt2phys mode is not enable the memory can still be accessed?

[weiqi7777]

If the hw virt2phys is not enable, openocd will use read the page to translate the virtual address to physical address, then use physicall address to write ebreak instruction into instruction region memory, that will not cause page fault exception.

But if hw virt2phys is enable, opencod will let hardware to translate the address, then to write ebreak instruction into instruction region memory，that will cause page fault exception.

As you mentioned, use the hardware breakpoint, that will limit the breakpoint number use, because hardware breakpoint is limit.

So we are curious, does OpenOCD not support this mode?

[aap-sc]

@weiqi7777

I think this is a defect actually, I'm not quite sure that it can be fixed easily, though.

@fk-sc, @en-sc , @MarekVCodasip FYI.

In my opinion for this specific case the final behavior should be functionally equivalent to the case when a SW translation mode was selected. Using HW breakpoints is not usable in all use cases due to resource constraints.

The case of setting/removing breakpoints alone can be fixed quite easily. GDB by itself does not give direct commands to read/write memory when setting SW breakpoints. Instead, GDB sends Z0/z0 packets to add/remove sw breakpoints. It is up to OpenOCD to decide what to do on behalf of these commands.

However, there is a more serious issue with GDB/OpenOCD in this mode. Namely, with stepi command. Before sending Z0/z0 packets GDB tries to read memory in order to detect "atomic region" (lr/sc sequence) to skip it. This is done using "memory read" commands (via x packet of gdb remote serial protocol). Since this is a separate packet - I don't see how we can differentiate it from ordinary read/writes. This specific issue may require more substantial changes in the codebase than a simple fix.

So for now I suggest to keep the issue open. I'm going to take a look at this issue in a greater detail once I have some time. For now I would treat this mode as not compatible with GDB.

[weiqi7777]

OK， thansk for your replay.

In my opinion, after setting the virt2phys command to hardware, OpenOCD should use hardware to perform address translation and retrieve data for data accesses, thereby accelerating the data access process.

However, for instruction region accesses or modifications (such as inserting ebreak instructions), software should be used to perform the address translation to obtain the physical address corresponding to the PC, and then use this physical address to access or modify the memory.

[aap-sc]

However, for instruction region accesses or modifications (such as inserting ebreak instructions), software should be used to perform the address translation to obtain the physical address corresponding to the PC, and then use this physical address to access or modify the memory.

Yes, the problem is that in GDB remote protocol there is no distinction between "instruction" and "data" addresses. The protocol uses just "memory access". Currently in OpenOCD there is no facilities to even describe the current memory map. That's the crux of the issue.