[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-riscv] [PATCH v2] RISC-V: Select FPU gdb xml file based on the

From: Jim Wilson
Subject: Re: [Qemu-riscv] [PATCH v2] RISC-V: Select FPU gdb xml file based on the supported extensions
Date: Tue, 20 Aug 2019 13:06:51 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

On 8/20/19 7:39 AM, Georg Kotheimer wrote:
The size of the FPU registers depends solely on the floating point
extensions supported by the target architecture.
However, in the previous implementation the floating point register
size was derived from whether the target architecture is 32-bit or

To allow RVF without RVD, changes to riscv_gdb_get_fpu() and
riscv_gdb_set_fpu() were necessary.

In addition fflags, frm and fcsr were removed from
riscv-XXbit-csr.xml, as the floating point csr registers are only
available, if a FPU is present.

The current XML files were identical to the XML files in gdb when implemented. This seems to be existing practice, as this is true of all of the other targets I looked at when I implemented this. Also, the file names are the same with a / replaced with a -. These files are in the gdb/features/riscv dir in a gdb source tree. It would be a shame to break this. I'm not sure if they are still identical. The gdb copies might have been updated since then, and may need to be copied into qemu to update qemu, but we don't have a dedicated gdb/qemu maintainer to do this.

I don't see a need to remove the fp csr's from the csr list. There are other extension dependent CSRs, like hypervisor ones. I think it makes more sense for the csr list to contain all of the csrs, and then disable access to them if that extension is not enabled. If there is a good reason to require changes to the csr XML files, then it probably should be discussed with the gdb developers too, so that the gdb and qemu copies of the files remain consistent.

Fixing the rvf/rvd 32/64-bit support is good. That is a bug in my original implementation.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]