Changed mmio_address in RzAnalysisOp to mmios[4]

[SSharshunov]

Your checklist for this pull request

• I've read the guidelines for contributing to this repository.
• I made sure to follow the project's coding style.
• I've documented every RZ_API function and struct this PR changes.
• I've added tests that prove my changes are effective (required for changes to RZ_API).
• I've updated the Rizin book with the relevant information (if needed).
• I've used AI tools to generate fully or partially these code changes and I'm sure the changes are not copyrighted by somebody else.

Detailed description

Replacing the single mmio_address with an mmios array

The single mmio_address field has been replaced with a 4-element array, mmios[4], and an mmios_count counter has been added. This change is necessary for devices or structures with multiple MMIO regions, allowing for the flexible handling of up to four addresses without altering the base type.
This field was previously used in only two places within a single architecture (AVR) and nowhere else.

Changed mmio_address in RzAnalysisOp to mmios[4] to fully replace register names from the SDBC database if multiple registers are used simultaneously.
For example:
add DPP3:0x025c, DPP0
add DPP3:0x025c, SORIC

Architecture changes from C166 have been moved to #6819

Test plan

CI is green

[codecov]

Codecov Report

❌ Patch coverage is 80.85106% with 9 lines in your changes missing coverage. Please review.
✅ Project coverage is 50.35%. Comparing base (046c88d) to head (ca7efa4).
⚠️ Report is 1 commits behind head on dev.

Files with missing lines	Patch %	Lines
librz/arch/p/analysis/analysis_c166.c	75.86%	2 Missing and 5 partials ⚠️
librz/arch/filter.c	80.00%	0 Missing and 1 partial ⚠️
librz/core/disasm.c	85.71%	0 Missing and 1 partial ⚠️

Additional details and impacted files

Files with missing lines	Coverage Δ
librz/arch/op.c	47.52% <100.00%> (+0.14%)	⬆️
librz/arch/p/analysis/analysis_avr.c	93.71% <100.00%> (+0.06%)	⬆️
librz/include/rz_analysis.h	72.72% <ø> (ø)
librz/arch/filter.c	62.40% <80.00%> (+0.13%)	⬆️
librz/core/disasm.c	67.43% <85.71%> (+<0.01%)	⬆️
librz/arch/p/analysis/analysis_c166.c	88.65% <75.86%> (+0.15%)	⬆️

... and 15 files with indirect coverage changes

---

Continue to review full report in Codecov by Harness.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2b8aa1a...ca7efa4. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Rot127]

Have you used AI by any chance for that one?
If yes, please check more carefully the changes before marking the PR as ready for review.

[SSharshunov]

Have you used AI by any chance for that one? If yes, please check more carefully the changes before marking the PR as ready for review.

I use Gemini only to find information about obscure architectural details. Sometimes I use to understand the Rizin internals, but I don't use copy-paste.

[SSharshunov]

In general, situations that seem to suggest AI use occur when I leave myself marks for future development, which reviewers then ask me to remove. As a result, some changes are lost in the future, resulting in illogical code.

[Rot127]

sure, no problem.
In general you can also use AI, even to write (some) code.
Just check it very carefully.

[wargio]

i do not understand the issue. how can there be multiple MMIO at the same address?

[SSharshunov]

i do not understand the issue. how can there be multiple MMIO at the same address?

I have mnemonics that represent several register names. While reverse engineering the RIZIN code, I noticed that values ​​like 0xfe06 are replaced with DPP3 if a value is set in mmio_address. A code search revealed that this is the only place where this field is used. So, I simply adapted the code for this architecture. There's also a place in AVR that uses this field.

[SSharshunov]

as example in Keil for c166 (address 0x0c)

[wargio]

for me that means that the map loaded for that rom image is wrong, and should load the correct one. i do not think you can just swap MMIO devices easily in AVR.

Is not an arch like the gameboy one where you have the concept of ram slots thus you have at the same address different data depending how a register is configured

[SSharshunov]

Is not an arch like the gameboy one where you have the concept of ram slots thus you have at the same address different data depending how a register is configured

Then I'm asking for help in explaining how memory mapping should work correctly so that the analysis can see a 24-bit address.

[wargio]

oh this kinda works like a page table. let me double check the changes

[wargio]

ok, so i think you should check if it matches with a DPPx register, then extract the upper 2 bits and print as DPP<upper 2 bits>:<remaining bits as hex>
you can keep the old mmio value and add an additional one for DPPx. maybe set it always to an invalid value, but when valid you print DPPn:offset

this is because you dont know what are the contents of DPP0-3 when disassembling

[wargio]

you can also do this directly when resolving the mmio. just map the address as DPP and when you resolve the address, check if DPP and extract the upper 2 bits and print the DPPn register before the offset

[Rot127]

Please rebase.

[SSharshunov]

Please rebase.

Done

[notxvilka]

Looks like it's a mix up of the different changes. Maybe it's better to extract non-MMIO things into separate PRs.

Please also update the PR description to be proper description.

[SSharshunov]

I split the changes into two PRs; this one contains only the MMIO-related changes.
Architecture changes from C166 have been moved to #6819

[Rot127]

Only these nitpicks.