riscv-software-src / riscv-tools

RISC-V Tools (ISA Simulator and Tests)
1.13k stars 446 forks source link

Remove the toolchain in riscv-tools #279

Closed palmer-dabbelt closed 5 years ago

palmer-dabbelt commented 5 years ago

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.

palmer-dabbelt commented 5 years ago

I'm making a sw-dev post and will let this sit until I remember it again.

jim-wilson commented 5 years ago

You should check to see if this breaks the rocket-chip repo.

aswaterman commented 5 years ago

@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.

aswaterman commented 5 years ago

However, this repo's CI will fail because it needs a RISC-V compiler :)

palmer-dabbelt commented 5 years ago

I just updated the PR to build a cross compiler via crosstool-ng, if that works then I'll merge this.

aswaterman commented 5 years ago

I fixed a few problems in the .travis.yml and now it's building...

aswaterman commented 5 years ago

@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.

aswaterman commented 5 years ago

@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.)

aswaterman commented 5 years ago

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.

jim-wilson commented 5 years ago

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.

aswaterman commented 5 years ago

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.

aswaterman commented 5 years ago

Hooray, it passes under that assumption.

RobertHenry6bev commented 5 years ago

Will this be merged in, or is it still baking?

aswaterman commented 5 years ago

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.

palmer-dabbelt commented 5 years ago

A green checkmark is good enough for me :)