-
-
Notifications
You must be signed in to change notification settings - Fork 791
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/formally parse riscv isa #2028
Merged
dragonmux
merged 8 commits into
blackmagic-debug:main
from
perigoso:feature/formally-parse-riscv-isa
Jan 16, 2025
Merged
Feature/formally parse riscv isa #2028
dragonmux
merged 8 commits into
blackmagic-debug:main
from
perigoso:feature/formally-parse-riscv-isa
Jan 16, 2025
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
e7438a6
to
962b631
Compare
8ecf22f
to
c6afbd4
Compare
c6afbd4
to
0db677d
Compare
dragonmux
approved these changes
Jan 16, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This all looks reasonable to us. We'll run a test with it on a couple of the RISC-V targets we have here, but please rebase this on main
and we'll get it merged presuming that all goes smoothly.
Thank you for the contribution!
write_char writes a single char into a char buffer at the provided offset, returns the offset incremented by 1 Memory safety safeguards are in place, if no buffer is provided, a buffer size of 0 is given, or the offset is out of bounds of the buffer, the buffer is not accessed, but the offset is still incremented Target use case is using in special print functions behaving similar to snprintf
RV32E base ISA devices have 16 GPRs while RV32I base ISA devices have 32, this is correctly reported to gdb in the target description xml, but when reading or writing all registers 32 registers were considered to be present
0db677d
to
1109a64
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Detailed description
This is a cherry-pick of a couple commits from #1399 that stand on their own as general improvements.
This adds more compreensive parsing of the RISC-V ISA from the misa register when available, this is used to show a more complete ISA when a target is probed.
Example with a RP2350 which is the only RISC-V target I have on hand:
before:
after:
The RP2350's formal ISA according to the datasheet is
rv32imac_zicsr_zifencei_zba_zbb_zbs_zbkb
(orrv32ima_zicsr_zifencei_zba_zbb_zbs_zbkb_zca_zcb_zcmp
with the most recent interpretation), so the BMP's parsing is correct.It's important to note, this only interprets the ISA standard ratified extensions, reserved extension bits are ignored for now, and since Z/X/S extensions cannot easily be detected (There's no CSR for them) they are "ignored" too.
Technically the presence of the 'B' extension can be interpreted as the
Zba
,Zbb
, andZbs
extensions being available, but in the interest of a cleaner ISA string we ignore it too.The 'I' is not directly intepreted because it is a base ISA, and is implicit unless the 'E' base ISA is set which we do check for. The 'E' bit is always the complement of 'I' only one is ever set, and one must be set.
This implementation could be cleaned up and be made much more efficient, but it works as is and can be improved later, submitting as is in the interest of getting merged before the v2.0 release
Your checklist for this pull request
Closing issues