Closed palmer-dabbelt closed 5 years ago
I'm making a sw-dev post and will let this sit until I remember it again.
You should check to see if this breaks the rocket-chip repo.
@jim-wilson it should be fine. It won't break rocket-chip immediately, because it points to an older commit hash. We can fix rocket-chip independently of this commit, or maintain a rocket-chip branch of riscv-tools that has the old behavior.
However, this repo's CI will fail because it needs a RISC-V compiler :)
I just updated the PR to build a cross compiler via crosstool-ng, if that works then I'll merge this.
I fixed a few problems in the .travis.yml and now it's building...
@palmer-dabbelt Still working on this. I've noticed that crosstool's attempt to download newlib fails around half of the time. I will have it retry the ct-ng build
command a couple times if it fails, but maybe you can think of a more robust solution.
@palmer-dabbelt it's getting further now... I needed to add a hack to copy some files around in the toolchain build, because out of the box it can't build executables. (The C headers are in the wrong place, as are crt0.o and libm.a.)
OK... I finally got it sort of working, but I think this version of gdb doesn't interact well with this version of openocd, or maybe with the debug tests. Not sure how we should proceed.
You need an FSF gdb with the RISC-V target description (aka xml) support. This will appear in gdb-8.3 which hasn't been released yet. Since it isn't a release yet, crosstools-ng doesn't use it. Even with that pending gdb release, there will still be a few failures. The python scripts in riscv-tests/debug need to be updated to match the new gdb output. Gdb used to print a NaN if you have a float value in a 64-bit FP reg. Now it does this gdb) print $fa0 $1 = {float = 2, double = -nan(0xfffff40000000)} (gdb) which is more useful, but riscv-tests/debug doesn't know how to parse that. There may also be a couple of other misc failures. The FP reg one if the main one that I remember.
We have a workaround for the gdb problem in riscv-gnu-toolchain mainline, and are using gdb mainline development instead of the last release. I suppose it might be possible to add support to crosstools to do something similar, but someone would have to do some crosstools work to add an alternate gdb package for RISC-V.
I propose we XFAIL the failing tests for now, rather than spending time to do something custom that we're going to throw away later.
Hooray, it passes under that assumption.
Will this be merged in, or is it still baking?
It's up to @palmer-dabbelt but I think it is sufficiently baked. The remaining major issue with gdb and the debug tests can be fixed separately.
A green checkmark is good enough for me :)
The toolchain pointed to by riscv-tools hasn't been maintained for more than a year now. This pointer was necessary when we had out-of-tree ports of the various toolchain components, but now that everything is upstream toolchains can be obtained via dozens of standard mechanisms. Having a broken toolchain so publicly visible causes everyone headaches, so unless someone wants to step up and maintain this I'm going to remove it.