Skip to content
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

Tests elf files #114

Open
abukharmeh opened this issue Oct 11, 2021 · 2 comments
Open

Tests elf files #114

abukharmeh opened this issue Oct 11, 2021 · 2 comments

Comments

@abukharmeh
Copy link
Contributor

Hi,

I wonder if it still make sense to keep tests elf files precompiled in test/riscv-tests ? I think it make more sense to add riscv-arch-test repo as a git submodule of this repository.

Also maybe we should add a new task to CI to compile and run these tests and make sure they all pass on each PR ?

Kind regards,
Ibrahim.

@abukharmeh abukharmeh changed the title Testing strategy for the model Tests elf files Oct 11, 2021
@jrtc27
Copy link
Collaborator

jrtc27 commented Oct 11, 2021

Precompiled binaries reduce the barrier to entry for development on the model, as it's quick and easy to run the tests, no need to mess about making sure you have the right toolchain (though LLVM makes that a lot easier). But committing binaries is also not great practice. So it's a trade-off.

Submodules are a bad idea IMO though. The tooling around them isn't great, and can be awkward for those less familiar with git. You also keep all the downsides of vendoring code (that it gets outdated) with about the only benefit being not having extra copies of things bloating repos. I don't think that makes sense as a choice. Instead you probably want a decoupled model of "point sail-riscv at a clone of the test suite and run it", though that relies on said test suite being mature enough to have a stable interface. As for riscv-arch-test specifically, it seems to be overly complicated and poorly designed (every implementation requires its own copy pasta tree of yet more copy pasta between extensions), and I don't understand the future of it when RISCOF is supposedly going to supersede it (which has its own poorly designed way to adapt to different models, keeping some of the copy pasta but instead forcing it out of a centralised repo into each implementation's repo so it's going to get even more out of sync).

@abukharmeh
Copy link
Contributor Author

I opened this issue because the test files in this repo are out of date, and that need to addressed somehow.

I suggested submodules because we can just track the arch test repo, and use all tests they add for various new extension without a lot of hassle. If precompiled bins are a must, then maybe GH actions can be used to compile them either on this repo, or arch-test one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants