Implement CMake build system

[Timmmm]

Switch from Makefiles to CMake. Some formal outputs are not yet fully supported by the CMake so the old Makefile is retained.

CMake has significant advantages:

• IDE support is perfect, since it generates compile_commands.json. You can even go-to-definition to the generated code (I can demo this in the meeting if people want). Lots of IDEs also understand CMake and CTest.
• Building all the emulators and running the tests is easy, parallel, and can generate an XML test result file (I haven't tested this though).
• Better Windows support, e.g. CMake can generate Visual Studio project files.

This also adds a manual Github actions workflow to generate the JSON doc bundle, to allow inclusion of Sail snippets in the ISA manual.

[arichardson]

Overall this is looking good!
I've left a few CMake comments, but it's quite hard to review with the softfloat upgrade included here.

[Timmmm]

Thanks for the review! I've split the other changes out into separate commits, so the CMake stuff is just the last commit now and hopefully easier to review.

I might drop the upgrade to softfloat actually since it didn't really change the code and hopefully we'll remove it at some point anyway in favour of the pure Sail implementation.

[jordancarlin]

I think it probably makes sense to skip the softfloat upgrade for the reasons you mentioned, but if we do decide to keep it I have some suggestions so that you don’t have to modify their Makefile.

[arichardson]

Regarding the commit that suggests bundling GMP - we could also use https://cmake.org/cmake/help/latest/module/ExternalProject.html#examples to build a known version statically (either opt-in or by default).

[arichardson]

A few minor comments but generally looks good to me.

[Timmmm]

if we do decide to keep it I have some suggestions so that you don’t have to modify their Makefile.

We aren't actually using their Makefile at all with the CMake version; I just kept the modifications so that it compiled as a standalone commit. I'll just remove the upgrade anyway though.

@arichardson I think you put a comment somewhere that I can't find now about keeping the Makefile. I think I'll just try and implement all of the features currently in the Makefile before merging this, rather than have two build systems...

[arichardson]

Adding all the other targets may take quite a while, maybe easiest for now to add CMake support and remove targets from the Makefile as we port them over?

E.g. this PR just removes the csim target (or rather have it defer to CMake cmake -S . -B $(BUILD_DIR) -DCMAKE_BUILD_TYPE=Release && $(MAKE) -C $(BUILD_DIR)) and then later commits add the extra features? Otherwise I worry this will be a long standing feature branch that never gets merged.

[jrtc27]

Adding all the other targets may take quite a while, maybe easiest for now to add CMake support and remove targets from the Makefile as we port them over?

E.g. this PR just removes the csim target (or rather have it defer to CMake cmake -S . -B $(BUILD_DIR) -DCMAKE_BUILD_TYPE=Release && $(MAKE) -C $(BUILD_DIR)) and then later commits add the extra features? Otherwise I worry this will be a long standing feature branch that never gets merged.

Doing CMake incrementally makes sense to me, but I'd rather not incrementally remove things from Makefile. It's annoying to have to use both depending on what you want to do. I don't really see the benefit of it. Just leave Makefile alone until it's entirely subsumed by CMakeLists.txt and then delete it.

[arichardson]

Adding all the other targets may take quite a while, maybe easiest for now to add CMake support and remove targets from the Makefile as we port them over?
E.g. this PR just removes the csim target (or rather have it defer to CMake cmake -S . -B $(BUILD_DIR) -DCMAKE_BUILD_TYPE=Release && $(MAKE) -C $(BUILD_DIR)) and then later commits add the extra features? Otherwise I worry this will be a long standing feature branch that never gets merged.

Doing CMake incrementally makes sense to me, but I'd rather not incrementally remove things from Makefile. It's annoying to have to use both depending on what you want to do. I don't really see the benefit of it. Just leave Makefile alone until it's entirely subsumed by CMakeLists.txt and then delete it.

That sounds even better to me

[billmcspadden-riscv]

I agree.

…

On Thu, Jan 9, 2025 at 2:12 PM Alexander Richardson < ***@***.***> wrote: Adding all the other targets may take quite a while, maybe easiest for now to add CMake support and remove targets from the Makefile as we port them over? E.g. this PR just removes the csim target (or rather have it defer to CMake cmake -S . -B $(BUILD_DIR) -DCMAKE_BUILD_TYPE=Release && $(MAKE) -C $(BUILD_DIR)) and then later commits add the extra features? Otherwise I worry this will be a long standing feature branch that never gets merged. Doing CMake incrementally makes sense to me, but I'd rather not incrementally remove things from Makefile. It's annoying to have to use both depending on what you want to do. I don't really see the benefit of it. Just leave Makefile alone until it's entirely subsumed by CMakeLists.txt and then delete it. That sounds even better to me — Reply to this email directly, view it on GitHub <#647 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AXROLOBMH4VMSUCF5IGWAX32J3JZ3AVCNFSM6AAAAABT2RMBV2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOBRGE3DGMZRGE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Bill McSpadden Formal Verification Engineer RISC-V International mobile: 503-807-9309

[Timmmm]

I've rebased it, removed the c_emulator rename and the softfloat update (we can do that later), and added RVFI support. I also updated the CI scripts.

I'm not sure I'm much of a fan of having two build systems during a transition. Verilator has exactly this - an old ./configure && make and an "experimental" CMake build system, and IMO it is quite confusing for users, and probably annoying for developers.

I reckon I can add the other targets without too much trouble, assuming they still work anyway! They aren't tested by CI and are presumably very rarely used.

[arichardson]

Need to keep makefile for now for the prover stuff?

[arichardson]

Overall I still think this is a great change. A few things that were supported are no longer there.

I wonder if we should keep the Makefile for now and add something like the following to the top:

ifndef I_REALLY_NEED_TO_USE_MAKE
$(error The Makefile build system is deprecated, please use CMake instead. If you are using a target that does not exist there yet, please file and issue and re-run make with I_REALLY_NEED_TO_USE_MAKE=1 until this has been fixed)
endif

[jordancarlin]

The Makefile is still pointing at the old location for softfloat. I know we want to encourage everyone to use the new CMake flow, but if we are going to keep the old Makefile around I think we should make sure it is still functional. Or remove the c emulator targets from it and only leave the formal backends.

[Timmmm]

Good point, I'll fix that. Also I think I forgot to do the RelWithDebInfo change - I'll do that in the morning.

[jordancarlin]

My other concern is changing the name of the generated executable itself. Currently it's riscv_sim_ARCH, which makes it clear what it is if copied to a bin directory. The switch to c_emulator_ARCH removes this easy recognition and doesn't seem to provide much benefit. If we want to explicitly call out that it is the c emulator (as opposed to the SystemVerilog one) maybe something like riscv_csim_ARCH would be better.

[Timmmm]

I rebased it, updated it for the Coq output (which now builds with the latest sail2 compiler, but it doesn't do everything the Makefile does), and also added a Github actions workflow to generate the JSON docs.

My aim for the latter is to run it manually and make a Github Release with it attached, so we can start including Sail snippets in the ISA manual (as we do for CHERI).

[arichardson]

Minor suggestion on the CI file but still LGTM

[github-actions]

Test Results

392 tests   - 4   392 ✅  - 4   49s ⏱️ +49s
  1 suites  - 3     0 💤 ±0 
  1 files   ±0     0 ❌ ±0 

Results for commit 8f62c29. ± Comparison against base commit 8a75b29.

This pull request removes 396 and adds 392 tests. Note that renamed tests count towards both.

Building 32-bit RISCV C emulator
Building 32-bit RISCV RVFI C emulator
Building 64-bit RISCV C emulator
Building 64-bit RISCV RVFI C emulator
C-32 rv32mi-p-breakpoint.elf
C-32 rv32mi-p-csr.elf
C-32 rv32mi-p-illegal.elf
C-32 rv32mi-p-ma_addr.elf
C-32 rv32mi-p-ma_fetch.elf
C-32 rv32mi-p-mcsr.elf
…

rv32d_rv32mi-p-breakpoint.elf ‑ rv32d_rv32mi-p-breakpoint.elf
rv32d_rv32mi-p-csr.elf ‑ rv32d_rv32mi-p-csr.elf
rv32d_rv32mi-p-illegal.elf ‑ rv32d_rv32mi-p-illegal.elf
rv32d_rv32mi-p-ma_addr.elf ‑ rv32d_rv32mi-p-ma_addr.elf
rv32d_rv32mi-p-ma_fetch.elf ‑ rv32d_rv32mi-p-ma_fetch.elf
rv32d_rv32mi-p-mcsr.elf ‑ rv32d_rv32mi-p-mcsr.elf
rv32d_rv32mi-p-sbreak.elf ‑ rv32d_rv32mi-p-sbreak.elf
rv32d_rv32mi-p-scall.elf ‑ rv32d_rv32mi-p-scall.elf
rv32d_rv32mi-p-shamt.elf ‑ rv32d_rv32mi-p-shamt.elf
rv32d_rv32si-p-csr.elf ‑ rv32d_rv32si-p-csr.elf
…

♻️ This comment has been updated with latest results.

[jordancarlin]

Definitely more optimizations to make in the future, but at this point this seems good to go now that CI is properly functioning again.

[Timmmm]

Ok I will merge this later today!

[jrtc27]

Test Results

392 tests   - 4   392 ✅  - 4   49s ⏱️ +49s   1 suites  - 3     0 💤 ±0    1 files   ±0     0 ❌ ±0 

Results for commit 8818308. ± Comparison against base commit 8a75b29.

This pull request removes 396 and adds 392 tests. Note that renamed tests count towards both.

Why have we lost 4 tests and 3 suites?

[Timmmm]

Why have we lost 4 tests and 3 suites?

Good question - the 4 lost are because the old output had compiling the models as tests.

Building 32-bit RISCV C emulator
Building 32-bit RISCV RVFI C emulator
Building 64-bit RISCV C emulator
Building 64-bit RISCV RVFI C emulator

The 3 suites are because the previous test runner script split the tests up into suites based on the above 4 models. In the new version they are combined.

I double checked that it is running all the same tests. You can see the list on the build CI job.

Note, the old script compiles the RVFI emulators but doesn't actually run any tests on them. This CMake version does the same.