Fix: add a remap for three RISC-V FPU CSR for GDB #2224

ALTracer commented 2026年04月04日 11:19:42 +02:00

Detailed description

• This is a small fix/follow-up to #1766.
• The existing problem is GDB p-packet (read single register) for CSR fflags, frm, fcsr (66, 67, 68) ending up remapped wrong for riscv_csr_read() layer. In particular, this was reported to generate errors in VSCode debug.
• This PR solves it by adding a couple if-branches to remap the three FPU CSRs appropriately.

Not tested, a RISC-V processor with F-extension is required.
There was a technically unhandled range from 66 up to 128 that used to get remapped to 0x1020 like this, I'm not sure if it should be blocked, or whether it's already unreachable thanks to riscv_build_target_description().
Should the debugger (BMD) enable the FPU when it's present but disabled (default from power-up) by user to conserve power etc.? Then such reads shouldn't ever fail...

Your checklist for this pull request

• I've read the Code of Conduct
• I've read the guidelines for contributing to this repository
• It builds for hardware native (see Building the firmware)
• It builds as BMDA (see Building the BMDA)
• I've tested it to the best of my ability
• My commit messages provide a useful short description of what the commits do

Closing issues

## Detailed description * This is a small fix/follow-up to #1766. * The existing problem is GDB p-packet (read single register) for CSR `fflags`, `frm`, `fcsr` (66, 67, 68) ending up remapped wrong for `riscv_csr_read()` layer. In particular, this was reported to generate errors in VSCode debug. * This PR solves it by adding a couple if-branches to remap the three FPU CSRs appropriately. Not tested, a RISC-V processor with F-extension is required. There was a technically unhandled range from 66 up to 128 that used to get remapped to 0x1020 like this, I'm not sure if it should be blocked, or whether it's already unreachable thanks to `riscv_build_target_description()`. Should the debugger (BMD) enable the FPU when it's present but disabled (default from power-up) by user to conserve power etc.? Then such reads shouldn't ever fail... ## Your checklist for this pull request * [x] I've read the [Code of Conduct](https://codeberg.org/blackmagic-debug/blackmagic/src/CODE_OF_CONDUCT.md) * [x] I've read the [guidelines for contributing](https://codeberg.org/blackmagic-debug/blackmagic/src/CONTRIBUTING.md) to this repository * [x] It builds for hardware native (see [Building the firmware](https://codeberg.org/blackmagic-debug/blackmagic?tab=readme-ov-file#building-the-firmware)) * [x] It builds as BMDA (see [Building the BMDA](https://codeberg.org/blackmagic-debug/blackmagic?tab=readme-ov-file#building-black-magic-debug-app)) * [ ] I've tested it to the best of my ability * [x] My commit messages provide a useful short description of what the commits do ## Closing issues