Add support for static compilation and binary release workflow

[Timmmm]

Add -DSTATIC=TRUE (not tested on Mac yet), and a release.yml CI workflow to build the emulators. That also doesn't have the Mac version enabled yet because we don't have a binary release of the Sail compiler for Mac yet, but that is coming.

[github-actions]

Test Results

392 tests  ±0   392 ✅ ±0   1m 19s ⏱️ -1s
  1 suites ±0     0 💤 ±0 
  1 files   ±0     0 ❌ ±0 

Results for commit 0297158. ± Comparison against base commit 025dcfc.

♻️ This comment has been updated with latest results.

[Timmmm]

Ok this works and generates the following emulators.

emulators.zip

They don't have any dependencies except glibc 2.17 (from 2012):

❯ ldd riscv_sim_rv64d 
	linux-vdso.so.1 (0x00007ffc0a9e5000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fe1352a4000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fe13567a000)

❯ ./riscv_sim_rv64d
No elf file provided.
Usage: ./riscv_sim_rv64d [options] <elf_file> [<elf_file> ...]
	 -d	 --enable-dirty-update
	 -m	 --enable-misaligned
	   	 --pmp-count
	   	 --pmp-grain
	 -z	 --ram-size
	 -C	 --disable-compressed
	 -I	 --disable-writable-misa
	 -F	 --disable-fdext
	 -i	 --mtval-has-illegal-inst-bits
	 -b	 --device-tree-blob
	 -t	 --terminal-log
	 -p	 --show-times
	 -a	 --report-arch
	 -T	 --test-signature
	 -g	 --signature-granularity
	 -h	 --help
	 -v	 --trace
	 -V	 --no-trace
	   	 --trace-output
	 -l	 --inst-limit
	 -x	 --enable-zfinx
	   	 --enable-writable-fiom
	   	 --enable-svinval
	   	 --enable-zcb
	   	 --enable-zicbom
	   	 --enable-zicboz
	   	 --cache-block-size

It's a little tricky to test the CI changes before they are merged, but as far as I can tell it's fine.

I suggest we merge this and then do a release. @billmcspadden-riscv

[jordancarlin]

The static compilation support LGTM. In terms of releases, it would be good to have the workflow create the release and upload the binaries to it so to generate a new release all that needs to be done is trigger a run of the workflow. Right now it looks like the binaries would need to be manually uploaded to the release after they are generated.

[Timmmm]

I agree, but I think we can do that in a future PR.

Also I've done that in the past, e.g. here but it ended up being a bit unsatisfying. I can't remember the details but it was something like you make a release, and then it triggers the workflow and eventually attaches the binaries (if CI passes). Kind of backwards - you really want to trigger the workflow with a release message as input, and then it creates the release at the end...

Maybe that's possible but I didn't look into it. It's not much work to do releases manually really.

[jordancarlin]

I'm fine with it being in a subsequent PR.

We definitely want it to be triggering the workflow that creates the release if we do go that route. I believe it is possible using the GitHub CLI, which should be usable in the GitHub Actions Runners. I can look into it.

[jordancarlin]

@Timmmm Took a look and I think I have a modified version of the action working for automatic releases. See https://github.com/jordancarlin/sail-riscv/blob/auto-release/.github/workflows/release.yml.

When you go to manually start a run of it (which is its only trigger), you are prompted to fill in the following information:

This then automatically creates the release and uploads the binaries to it. Result of test run can be seen here: https://github.com/jordancarlin/sail-riscv/releases/tag/v0.0.0-test3

[Timmmm]

Ah sweet, that was fast and looks easier than I was expecting! I'll update this PR with your version.

[jordancarlin]

Integration of my changes look good.

A few other thoughts:

• We should probably run the tests on the generated binary before uploading it to ensure everything is working before creating a release with it.
• Maybe enable generate_release_notes if the manually filled in release notes are blank. This uses the default GitHub release notes consisting of a list of merged PRs and contributors. Or we could always enable this and it will automatically prepend it with any custom release notes we add to the body option.
• When we enable macOS we’ll need to ensure each uploaded artifact has a unique name. This might be worth doing now so the names don’t need to change later. Maybe creating a tarball with both the rv32 and rv64 simulators in it and naming it something like riscv_sim-OS.