forked from Imagelibrary/binutils-gdb
4749b84b51
First, some background on the RISC-V registers fflags, frm, and fcsr. These three registers all relate to the floating-point status and control mechanism on RISC-V. The fcsr is the floatint-point control status register, and consists of two parts, the flags (bits 0 to 4) and the rounding-mode (bits 5 to 7). The fcsr register is just one of many control/status registers (or CSRs) available on RISC-V. The fflags and frm registers are also CSRs. These CSRs are aliases for the relevant parts of the fcsr register. So fflags is an alias for bits 0 to 4 of fcsr, and frm is an alias for bits 5 to 7 of fcsr. This means that a user can change the floating-point rounding mode either, by writing a complete new value into fcsr, or by writing just the rounding mode into frm. How this impacts on GDB is like this: a target description could, legitimately include all three registers, fcsr, fflags, and frm. The QEMU target currently does this, and this makes sense. The target is emulating the complete system, and has all three CSRs available, so why not tell GDB about this. In contrast, the RISC-V native Linux target only has access to the fcsr. This is because the ptrace data structure that the kernel uses for reading and writing floating point state only contains a copy of the fcsr, after all, this one field really contains both the fflags and frm fields, so why carry around duplicate data. So, we might expect that the target description for the RISC-V native Linux GDB would only contain the fcsr register. Unfortunately, this is not the case. The RISC-V native Linux target uses GDB's builtin target descriptions by calling riscv_lookup_target_description, this will then add an fpu feature from gdb/features/riscv, either 32bit-fpu.xml or 64bit-fpu.xml. The problem, is that these features include an entry for fcsr, fflags, and frm. This means that GDB expects the target to handle reading and writing these registers. And the RISC-V native Linux target currently doesn't. In riscv_linux_nat_target::store_registers and riscv_linux_nat_target::fetch_registers only the fcsr register is handled, this means that, for RISC-V native Linux, the fflags and frm registers always show up as <unavailable> - they are present in the target description, but the target doesn't know how to access the registers. A final complication relating to these floating pointer CSRs is which target description feature the registers appear in. These registers are CSRs, so it would seem sensible that these registers should appear in the CSR target description feature. However, when I first added RISC-V target description support, I was using a RISC-V simulator that didn't support any CSRs other than the floating point related ones. This simulator bundled all the float related CSRs into the fpu target feature. This didn't feel completely unreasonable to me, and so I had GDB check for these registers in either target feature. In this commit I make some changes relating to how GDB handles the three floating point CSR: 1. Remove fflags and frm from 32bit-fpu.xml and 64bit-fpu.xml. This means that the default RISC-V target description (which RISC-V native FreeBSD), and the target descriptions created for RISC-V native Linux, will not include these registers. There's nothing stopping some other target (e.g. QEMU) from continuing to include all three of these CSRs, the code in riscv-tdep.c continues to check for all three of these registers, and will handle them correctly if they are present. 2. If a target supplied fcsr, but does not supply fflags and/or frm, then RISC-V GDB will now create two pseudo registers in order to emulate the two missing CSRs. These new pseudo-registers do the obvious thing of just reading and writing the fcsr register. 3. With the new pseudo-registers we can no longer make use of the GDB register numbers RISCV_CSR_FFLAGS_REGNUM and RISCV_CSR_FRM_REGNUM. These will be the numbers used if the target supplies the registers in its target description, but, if GDB falls back to using pseudo-registers, then new, unique numbers will be used. To handle this I've added riscv_gdbarch_tdep::fflags_regnum and riscv_gdbarch_tdep::frm_regnum, I've then updated the RISC-V code to compare against these fields. When adding the pseudo-register support, it is important that the pseudo-register numbers are calculated after the call to tdesc_use_registers. This is because we don't know the total number of physical registers until after this call, and the psuedo-register numbers must follow on from the real (target supplied) registers. I've updated some tests to include more testing of the fflags and frm registers, as well as adding a new test.
136 lines
4.7 KiB
Plaintext
136 lines
4.7 KiB
Plaintext
# Copyright 2003-2022 Free Software Foundation, Inc.
|
|
|
|
# This program is free software; you can redistribute it and/or modify
|
|
# it under the terms of the GNU General Public License as published by
|
|
# the Free Software Foundation; either version 3 of the License, or
|
|
# (at your option) any later version.
|
|
#
|
|
# This program is distributed in the hope that it will be useful,
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
# GNU General Public License for more details.
|
|
#
|
|
# You should have received a copy of the GNU General Public License
|
|
# along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
# Please email any bugs, comments, and/or additions to this file to:
|
|
# bug-gdb@gnu.org
|
|
|
|
# This file is part of the gdb testsuite.
|
|
|
|
#
|
|
# Test floating-point related functionality.
|
|
#
|
|
|
|
|
|
if { [prepare_for_testing "failed to prepare" float float.c] } {
|
|
return -1
|
|
}
|
|
|
|
# Set it up at a breakpoint so we have its registers.
|
|
|
|
if ![runto_main] then {
|
|
perror "couldn't run to breakpoint"
|
|
return
|
|
}
|
|
|
|
# Test "info float".
|
|
|
|
if { [is_aarch64_target] } then {
|
|
gdb_test "info float" "d0.*d1.*d31.*s0.*s1.*s31.*"
|
|
} elseif { [istarget "alpha*-*-*"] } then {
|
|
gdb_test "info float" "f0.*"
|
|
} elseif { [is_aarch32_target] } then {
|
|
gdb_test_multiple "info float" "info float" {
|
|
-re "Software FPU type.*mask:.*flags:.*$gdb_prompt $" {
|
|
pass "info float (FPA)"
|
|
}
|
|
-re "fpscr.*s0.*s1.*s31.*$gdb_prompt $" {
|
|
# Only check for single precision; d0 might be a vector register
|
|
# if we have NEON.
|
|
pass "info float (VFP)"
|
|
}
|
|
-re "No floating.point info available for this processor.*$gdb_prompt $" {
|
|
pass "info float (without FPU)"
|
|
}
|
|
}
|
|
} elseif { [istarget "i?86-*-*"] || [istarget "x86_64-*-*"] } then {
|
|
gdb_test "info float" "R7:.*Status Word:.*Opcode:.*"
|
|
} elseif [istarget "ia64-*-*"] then {
|
|
gdb_test "info float" "f0.*f1.*f127.*"
|
|
} elseif [istarget "m68k-*-*"] then {
|
|
gdb_test_multiple "info float" "info_float" {
|
|
-re "fp0.*fp1.*fp7.*$gdb_prompt $" {
|
|
pass "info float (with FPU)"
|
|
}
|
|
-re "No floating.point info available for this processor.*$gdb_prompt $" {
|
|
pass "info float (without FPU)"
|
|
}
|
|
}
|
|
} elseif [istarget "mips*-*-*"] then {
|
|
gdb_test_multiple "info float" "info float" {
|
|
-re "fpu type: none / unused\r\n$gdb_prompt $" {
|
|
pass "info float (without FPU)"
|
|
}
|
|
-re "fpu type:.*cause.*mask.*flags.*round.*flush.*f0:.*flt:.*dbl:.*$gdb_prompt $" {
|
|
pass "info float (with FPU)"
|
|
}
|
|
}
|
|
} elseif [istarget "nds32*-*-*"] then {
|
|
gdb_test_multiple "info float" "info_float" {
|
|
-re "fd0.*fd3.*$gdb_prompt $" {
|
|
pass "info float (with FPU)"
|
|
}
|
|
-re "No floating.point info available for this processor.*$gdb_prompt $" {
|
|
pass "info float (without FPU)"
|
|
}
|
|
}
|
|
} elseif [istarget "powerpc*-*-*"] then {
|
|
gdb_test_multiple "info float" "info_float" {
|
|
-re "f0.*f1.*f31.*fpscr.*$gdb_prompt $" {
|
|
pass "info float (with FPU)"
|
|
}
|
|
-re "No floating.point info available for this processor.*$gdb_prompt $" {
|
|
pass "info float (without FPU)"
|
|
}
|
|
}
|
|
} elseif [istarget "s390*-*-*"] then {
|
|
gdb_test "info float" "fpc.*f0.*f1.*f15.*" "info float"
|
|
} elseif [istarget "sh*-*"] then {
|
|
# SH may or may not have an FPU
|
|
gdb_test_multiple "info float" "info float" {
|
|
-re "fpul.*fr0.*fr1.*fr15.*$gdb_prompt $" {
|
|
pass "info float (with FPU)"
|
|
}
|
|
-re "No floating.point info available for this processor.*$gdb_prompt $" {
|
|
pass "info float (without FPU)"
|
|
}
|
|
}
|
|
} elseif [istarget "hppa*-*"] then {
|
|
gdb_test "info float" "fr4.*fr4R.*fr31R.*" "info float"
|
|
} elseif [istarget "sparc*-*-*"] then {
|
|
gdb_test "info float" "f0.*f1.*f31.*d0.*d30.*" "info float"
|
|
} elseif [istarget "riscv*-*-*"] then {
|
|
# RISC-V may or may not have an FPU. Additionally, the order of
|
|
# fcsr relative to fflags and frm can change depending on whether
|
|
# the fflags and frm registers are implemented as real registers
|
|
# (supplied in the target description) or pseudo-registers
|
|
# (supplied by GDB as a view into fcsr).
|
|
gdb_test_multiple "info float" "info float" {
|
|
-re "ft0.*ft1.*ft11.*fflags.*frm.*fcsr.*$gdb_prompt $" {
|
|
pass "info float (with FPU)"
|
|
}
|
|
-re "ft0.*ft1.*ft11.*fcsr.*fflags.*frm.*$gdb_prompt $" {
|
|
pass "info float (with FPU)"
|
|
}
|
|
-re "No floating.point info available for this processor.*$gdb_prompt $" {
|
|
pass "info float (without FPU)"
|
|
}
|
|
}
|
|
} else {
|
|
gdb_test "info float" "No floating.point info available for this processor." "info float (unknown target)"
|
|
}
|
|
|
|
gdb_test "step"
|
|
gdb_test "finish" "Value returned is .* = (inf|nan).*"
|