Reduce size of compiled tests

[ZiaCheemaGit]

✗ FAILED: I-andi-00.sig
  Output: work/single_cycle_rv32i_core/build/rv32i/I/I-andi-00.sig.elf
  Error output:
    /home/zia-cheema/Desktop/git-clones/riscv64-elf-ubuntu-22.04-gcc/riscv/riscv64-unknown-elf/bin/ld: /home/zia-cheema/Desktop/git-clones/riscv-arch-test-act4/work/single_cycle_rv32i_core/build/rv32i/I/I-andi-00.sig.elf section `.text' will not fit in region `ROM'
    /home/zia-cheema/Desktop/git-clones/riscv64-elf-ubuntu-22.04-gcc/riscv/riscv64-unknown-elf/bin/ld: /home/zia-cheema/Desktop/git-clones/riscv-arch-test-act4/work/single_cycle_rv32i_core/build/rv32i/I/I-andi-00.sig.elf section `.data' will not fit in region `RAM'
    /home/zia-cheema/Desktop/git-clones/riscv64-elf-ubuntu-22.04-gcc/riscv/riscv64-unknown-elf/bin/ld: section .data VMA [00002000,00018cdf] overlaps section .text VMA [00000000,00003fff]
    /home/zia-cheema/Desktop/git-clones/riscv64-elf-ubuntu-22.04-gcc/riscv/riscv64-unknown-elf/bin/ld: region `ROM' overflowed by 15104 bytes
    /home/zia-cheema/Desktop/git-clones/riscv64-elf-ubuntu-22.04-gcc/riscv/riscv64-unknown-elf/bin/ld: region `RAM' overflowed by 91656 bytes
    /home/zia-cheema/Desktop/git-clones/riscv64-elf-ubuntu-22.04-gcc/riscv/riscv64-unknown-elf/bin/ld: warning: cannot find entry symbol _start; defaulting to 00000000
    collect2: error: ld returned 1 exit status
  Reproduce with:
    /home/zia-cheema/Desktop/git-clones/riscv64-elf-ubuntu-22.04-gcc/riscv/bin/riscv64-unknown-elf-gcc \
      -I/home/zia-cheema/Desktop/git-clones/riscv-arch-test-act4/config/cores/my_cpu/rv32i \
      -T/home/zia-cheema/Desktop/git-clones/riscv-arch-test-act4/config/cores/my_cpu/rv32i/link.ld \
      -O0 \
      -g \
      -mcmodel=medany \
      -nostdlib \
      -I/home/zia-cheema/Desktop/git-clones/riscv-arch-test-act4/tests/env \
      -Wl,--no-warn-rwx-segments \
      -o /home/zia-cheema/Desktop/git-clones/riscv-arch-test-act4/work/single_cycle_rv32i_core/build/rv32i/I/I-andi-00.sig.elf \
      -march=rv32i_zicsr \
      -mabi=ilp32 \
      -DSIGNATURE \
      -DXLEN=32 \
      -DTEST_FLEN=32 \
      /home/zia-cheema/Desktop/git-clones/riscv-arch-test-act4/tests/rv32i/I/I-andi-00.S

✗ Build failed: 1 failed
make: *** [Makefile:168: elfs] Error 1
zia-cheema@zia-cheema-HP-EliteBook-840-G3:~/Desktop/git-clones/riscv-arch-test-act4$ 

I have to run ACTs on an RV32I. My core doesn't yet have csr and fence instructions implemented. I plan to implement those instructions but at a later stage in project timeline. Can't I run tests without them.
Also I have memory constraints. This above output is what I got after I ran make assuming csr is implemented, to atleast see generated tests, why is csr necessary.

Is this memory insufficient for just a single test or all tests. Are there any work arounds for this situation?

[davidharrishmc]

Yes, it is possible to build and run without csr instructions. See riscv-arch-test-dh/config/sail/sail-RVI20U32/rvmodel_macros.h // Custom RVMODEL_BOOT_TO_MMODE overrides default RVTEST_BOOT_TO_MMODE // if defined. For most DUTs, the default should work and this macro // should not be defined. If no M-mode or CSRs are implemented, define this // macro as blank to bypass the boot process. If a nonconforming // M-mode is implemented, define this macro to set up the necessary // state in a fashion similar to RVTEST_BOOT_TO_MMODE. #define RVMODEL_BOOT_TO_MMODE There are fence instructions automatically generated, but you could either have your core treat the as a nop, or delete them. Memory size is a concern. We don’t yet have a clean way to fit in a tiny memory footprint. If this is Verilog that you are testing, could you you bump up your memory sizes for testing? There may be ways to get rid of the error strings to save more memory, but that’s not on our priority list to implement right now.

…

On May 6, 2026, at 5:21 AM, Zia Cheema ***@***.***> wrote: ZiaCheemaGit created an issue (riscv/riscv-arch-test#1442) <#1442> ✗ FAILED: I-andi-00.sig Output: work/single_cycle_rv32i_core/build/rv32i/I/I-andi-00.sig.elf Error output: /home/zia-cheema/Desktop/git-clones/riscv64-elf-ubuntu-22.04-gcc/riscv/riscv64-unknown-elf/bin/ld: /home/zia-cheema/Desktop/git-clones/riscv-arch-test-act4/work/single_cycle_rv32i_core/build/rv32i/I/I-andi-00.sig.elf section `.text' will not fit in region `ROM' /home/zia-cheema/Desktop/git-clones/riscv64-elf-ubuntu-22.04-gcc/riscv/riscv64-unknown-elf/bin/ld: /home/zia-cheema/Desktop/git-clones/riscv-arch-test-act4/work/single_cycle_rv32i_core/build/rv32i/I/I-andi-00.sig.elf section `.data' will not fit in region `RAM' /home/zia-cheema/Desktop/git-clones/riscv64-elf-ubuntu-22.04-gcc/riscv/riscv64-unknown-elf/bin/ld: section .data VMA [00002000,00018cdf] overlaps section .text VMA [00000000,00003fff] /home/zia-cheema/Desktop/git-clones/riscv64-elf-ubuntu-22.04-gcc/riscv/riscv64-unknown-elf/bin/ld: region `ROM' overflowed by 15104 bytes /home/zia-cheema/Desktop/git-clones/riscv64-elf-ubuntu-22.04-gcc/riscv/riscv64-unknown-elf/bin/ld: region `RAM' overflowed by 91656 bytes /home/zia-cheema/Desktop/git-clones/riscv64-elf-ubuntu-22.04-gcc/riscv/riscv64-unknown-elf/bin/ld: warning: cannot find entry symbol _start; defaulting to 00000000 collect2: error: ld returned 1 exit status Reproduce with: /home/zia-cheema/Desktop/git-clones/riscv64-elf-ubuntu-22.04-gcc/riscv/bin/riscv64-unknown-elf-gcc \ -I/home/zia-cheema/Desktop/git-clones/riscv-arch-test-act4/config/cores/my_cpu/rv32i \ -T/home/zia-cheema/Desktop/git-clones/riscv-arch-test-act4/config/cores/my_cpu/rv32i/link.ld \ -O0 \ -g \ -mcmodel=medany \ -nostdlib \ -I/home/zia-cheema/Desktop/git-clones/riscv-arch-test-act4/tests/env \ -Wl,--no-warn-rwx-segments \ -o /home/zia-cheema/Desktop/git-clones/riscv-arch-test-act4/work/single_cycle_rv32i_core/build/rv32i/I/I-andi-00.sig.elf \ -march=rv32i_zicsr \ -mabi=ilp32 \ -DSIGNATURE \ -DXLEN=32 \ -DTEST_FLEN=32 \ /home/zia-cheema/Desktop/git-clones/riscv-arch-test-act4/tests/rv32i/I/I-andi-00.S ✗ Build failed: 1 failed make: *** [Makefile:168: elfs] Error 1 ***@***.***:~/Desktop/git-clones/riscv-arch-test-act4$ I have to run ACTs on an RV32I. My core doesn't yet have csr and fence instructions implemented. I plan to implement those instructions but at a later stage in project timeline. Can't I run tests without them. Also I have memory constraints. This above output is what I got after I ran make assuming csr is implemented, to atleast see generated tests, why is csr necessary. Is this memory insufficient for just a single test or all tests. Are there any work arounds for this situation? — Reply to this email directly, view it on GitHub <#1442>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AR4AA37BUCVB4PHTS4OYTYL4ZMU3XAVCNFSM6AAAAACYTAKVPKVHI2DSMVQWIX3LMV43ASLTON2WKOZUGM4TCMRVHE3DSMQ>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.

[ZiaCheemaGit]

David Harris (@davidharrishmc) yes I can bump up memories and I am on verilog but that just neglects the whole idea why I am running ACTs.
I developed minimal 5 C tests for the rv32i core and thought that because its the most base architecture I could get away by just proving those custom tests. Now I am at a stage where I am running C on the core on an FPGA which has max memory of 30KB. The core runs simple C programs perfectly in sim but misbehaves on FPGA. So the base of running ACTs was to run
them on FPGA.

[ZiaCheemaGit]

Still my project demands me to build up on rv32i almost 3 or 4 extensions and tapeout each iteration so memory will still be a constraint for me in future thus I am open to work on making the tests have minimal memory footprint. I am not at that position yet but was wondering that the easiest way of testing post silicon will be to have ACTs preloaded into silicon rom this will really save up alot of headache but on chip rom is expensive.
Would love if you could mentor where I can start and where is all the memory realted stuff

[davidharrishmc]

I'm sorry but we are on a crunch to get the suite of certification tests together by June, so I don't have bandwidth for a side project right now. It would be valuable to make the tests smaller. No effort has gone into that yet and there is undoubtedly low-hanging fruit. If you look at the object dump, you'll see what is going where, and may get some ideas. Many other people have started contributing to the ACT repo, so I think you'll find your way around how to make modifications if you choose to go that way.

Some easy things could be to study where there is empty space in the program memory and try to squeeze that out, add a flag to disable producing strings that identify which tests failed, turn off the -g debug symbols, and use a parameter in constants.py (I believe) that limits the number of tests going into each file.

[jordancarlin]

The easiest way to cut down the file size is using the TESTCASES_PER_FILE variable in generators/testgen/src/testgen/constants.py. It defaults to 1000, but reducing that will give you more tests that are each smaller. Unfortunately, due to other overhead (described in the previous message), the lower limit is about 100 KB right now.

[Maanvi212006]

Hi David Harris (@davidharrishmc) Jordan Carlin (@jordancarlin), thanks for the detailed pointers above. I'd like to work on reducing the test footprint and was hoping to pick this up as a starting contribution.
Based on the suggestions in this thread, I'm planning to investigate the following, likely as separate smaller PRs so each is easy to review/measure independently:

PR 1 : Making the -g debug flag conditional/removable and measuring the resulting size reduction
PR 2 : Looking into the failure-identification strings and whether these can be shortened or made optional via a build flag
PR 3 : Experimenting with TESTCASES_PER_FILE in constants.py to document the size/file-count tradeoff and see if the ~100KB floor can be pushed lower
PR 4 : If time permits, looking at the linker script / objdump output for any obvious padding or layout inefficiencies

I'll start with PR 1 and PR 3 since they seem most contained, and report back with before/after size numbers. Is f there a preferred way to benchmark this (e.g., a specific core/test combination to use as a baseline), or if any of these directions are not worth pursuing.

Let me know if this works. Once confirmed, I will get started!

[ZiaCheemaGit]

Maanvi212006 I think you won't need any specific core as there is nothing to execute. Maybe you can compile tests against a dummy linker with starting size > 300KB(whatever works) and go down from there parallel to your changes.

[davidharrishmc]

Maanvi212006 glad you are exploring this.

[BhargaviSV]

FOLLOWING UP OUR PREVIOUS QUERY
Our current hardware architecture : RV32IMFC_ZICSR_ZIFENCEI, 64KB ROM, 32KB RAM.

But each of the test cases from this test suite are exceeding our memory.
Is there a way to reduce memory usage to fit into our current architecture?

Jordan Carlin (@jordancarlin) David Harris (@davidharrishmc) We had raised this query yesterday and we were redirected here, after going through this thread we have tried the following but no observable reduction in size of elf

1. Removed the -g debug flag
2. TESTCASES_PER_FILE was reduced to 1, still .elf was ~100KB
3. Added custom ifdef to reduce unused trap functions in rvtest_failure_code.h

.data has not been reduced even after making all these changes, it has been the same throughout

Is there any other way to reduce this?

[davidharrishmc]

This is not something anyone has worked on closely yet. I expect there will be lo hanging fruit to reduce code size, but I don’t know what it is and these experiments have ruled some things out. I think you’ll need to study the code closely and understand where the size is coming from, what is fundamental, and what is accidental. Jordan and I would like to get there, but RVA23 is on the critical path, so we won’t be able to turn to this quickly. As a quick study, I look at work/spike-rv32-max/elfs/rv32i/M/M-mul-00.elf. It is 228 KB. tests/rv32i/M/M-mul-00.S is 257 KB but only contains 392 mul instructions. In the objdump, .text.rvtest size is 71c0 (29 KB) and .data is 19d80 (106 KB), and .debug_line is 10 KB, together making up most of the substntial sections. The .data section goes from 0x80008000 to 0xf510 to 0x21e00 but beyond 0x13300 it is all deadbeef. Thus only the first 46 KB has interesting stuff and the next 60 KB could be removed with more clever generation. Of that 46 KB, only up to 9280 (first 4.8 kB) contains data needed for tests and the other 41K is strings for error reporting that could be eliminated or compressed for small memory systems. Looking at the disassembly in the object dump starting at 0x80000040, each test case loads two sources, performs the multiply, and checks the results. This is 0x2C (44) bytes. Hence, the core of the .text.rvtest segment is 17 kB, confirmed by multiplication and also inspection of the object dump. The remaining 12 kB are trap handlers and failure reporting code. There is likely some bloat in the failure reporting code that could be reduced with human effort. Touching the trap handler is risky because there are a lot of ways to introduce error and not know about it because the code path wasn’t exercised yet. Without modifying failure reporting code, the essential code and data size seems to be 12 kB o overhead trap handler/reporting, 17 kB of tests, and 46 kB of data for 392 tests. The TESTCASES_PER_FILE parameter in generators/testgen/src/testgen/constants.py limits the number of test cases. Try adjusting that to 100. If you were to set a limit of 100 tests per file, that would divide into 4 files, each with 12 kB of overhead and 5 kb of tests in the code section, and 12 kB of data, comfortably fitting in your memory. So if you have time to dig deeper, I would suggest figuring out how to get rid of the 60 KB empty part of the data segment, turn off the debug segments, and split to 4 files, and then look at the object dump and see where other unnecessary elements are creeping into the file size.

…

On Jun 16, 2026, at 4:27 AM, Bhargavi S V ***@***.***> wrote: BhargaviSV left a comment (riscv/riscv-arch-test#1442) <#1442 (comment)> FOLLOWING UP OUR PREVIOUS QUERY Our current hardware architecture : RV32IMFC_ZICSR_ZIFENCEI, 64KB ROM, 32KB RAM. But each of the test cases from this test suite are exceeding our memory. Is there a way to reduce memory usage to fit into our current architecture? Jordan Carlin ***@***.***) <https://github.com/jordancarlin> David Harris ***@***.***) <https://github.com/davidharrishmc> We had raised this query yesterday and we were redirected here, after going through this thread we have tried the following but no observable reduction in size of elf Removed the -g debug flag TESTCASES_PER_FILE was reduced to 1, still .elf was ~100KB Added custom ifdef to reduce unused trap functions in rvtest_failure_code.h image.png (view on web) <https://github.com/user-attachments/assets/dcc3affd-03b6-4851-a00c-dd2ab2051358> .data has not been reduced even after making all these changes, it has been the same throughout Is there any other way to reduce this? — Reply to this email directly, view it on GitHub <#1442?email_source=notifications&email_token=AR4AA34H3MDOU6LTQNWWRRT5AEVJVA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZRHAZDEOJYHAZKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4718229882>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AR4AA36KMYBD2B7OQATDHKD5AEVJVAVCNFSNUABFKJSXA33TNF2G64TZHMYTGNBQGAZTSNBVHNEXG43VMU5TIMZZGEZDKOJWHEZKC5QC>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AR4AA36LFPECSDOHE52BJ6L5AEVJVA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZRHAZDEOJYHAZKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/AR4AA3Y53INS3CRIKPDKTPT5AEVJVA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZRHAZDEOJYHAZKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.

[Maanvi212006]

Hi David Harris (@davidharrishmc) , thank you for the detailed breakdown — this is really helpful in understanding where the size is actually coming from.
Based on the analysis, I'm updating my plan to reflect what the experiments and objdump study revealed:
What the experiments confirmed:

Removing -g and reducing TESTCASES_PER_FILE to 1 alone don't meaningfully reduce .data size
The real bloat is structural, not just compiler flags

Updated PR plan:
PR 1 — Fix empty .data padding:
The ~60KB of deadbeef padding beyond 0x13300 seems to be the single largest addressable problem. I'll dig into the generator to understand why this empty space is being emitted and fix it at the source.

PR 2 — Make error-reporting strings optional:
~41KB of .data is error-reporting strings. I'll add a build flag (e.g. MINIMAL_FOOTPRINT or similar) to disable/compress these for memory-constrained targets, while keeping them enabled by default so existing behavior is unchanged.

PR 3 — Document and validate TESTCASES_PER_FILE=100 as the recommended setting:
Your analysis confirms that 100 tests/file gives a comfortable fit for 64KB ROM. I'll validate this, document it clearly, and consider whether this default should change upstream.

PR 4 — Combine all of the above and measure:
Once PRs 1-3 are done, measure the combined effect with an objdump comparison to confirm the actual achievable floor.
A couple of questions before I dive in:

For PR 1, is the empty .data padding coming from the test generator in generators/testgen/ or somewhere in the linker script? I want to make sure I'm looking in the right place first.
Is there a preferred reference ELF to use as a baseline throughout (you mentioned work/spike-rv32-max/elfs/rv32i/M/M-mul-00.elf — should I use that)?

Thanks again for the detailed analysis — it really narrows down where the effort should go.