search

sifive / freedom-tools

Tools for SiFive's Freedom Platform
217 stars 52 forks source link

Bump toolchain version and update multilib list #9

Closed kito-cheng closed 5 years ago

kito-cheng commented 5 years ago
jim-wilson commented 5 years ago

This looks OK to me. freedom-tools is Carsten's repo though, so I would leave the final decision to him.

Before the patch, the local patches are at the top of the binutils, gcc, and newlib trees. After the patch, the local patches are not at the top. It isn't obvious how to get the local set of patches. This may make future maintenance harder, but not my problem if you are maintaining it.

The new MULTILIBS_GEN definition in Makefile has a trailing backslash. This is OK because it is followed by a blank line, but it might avoid future confusion if we drop that trailing backslash now.

jim-wilson commented 5 years ago

Some of the Optimitech patches required top level makefile changes. Since freedom-tools has its own top level makefile, those patches will have to be brought over too. Those are missing. There is a patch for the lite-exit support, and a patch to disable tm clones.

There is also a patch you added to build newlib in POSIX mode.

kito-cheng commented 5 years ago

After the patch, the local patches are not at the top. It isn't obvious how to get the local set of patches. This may make future maintenance harder, but not my problem if you are maintaining it.

My thought is don't force push to exists branch to prevent dangling commit, so I just use merge for binutils, but I think I can create tag to prevent that.

Other makefile stuffs I am working in progress, will update branch later.

cgsfv commented 5 years ago

I just merged the RC1 build setup into master, so I will look into this PR after that.

kito-cheng commented 5 years ago

ChangeLog:

cgsfv commented 5 years ago

Are the binutils, gcc and newlib submodules referencing top commits in branches for those repos and which ones?

For the freedom-tools master branch (and latest release) the submodules references top commit of branches to make it easier to navigate the repo structures: binutils: sifive-binutils-2.32 branch gcc: sifive-gcc-8.2.0 branch newlib: sifive-newlib-3.0.0 branch

Is the multilibs list updated to match the presentation and the table I created?

Besides that, it looks good.

cgsfv commented 5 years ago

How did the commit log remove the current 3 latest commits, when looking at this https://github.com/sifive/riscv-binutils-gdb/commits/sifive-binutils-2.32?before=164267155c96f91472a539ca78ac919993bc5b4e+35

jim-wilson commented 5 years ago

The commit logs were not removed. Kito merged the upstream tree into the SiFive tree, instead of rebasing or merging the SiFive patches into the upstream tree. So all of the SiFive patches are there, they are just farther down in the commit log.

Also note that some of the patches that we had to manually add in the last release are now upstream at the FSF and upstream in the riscv/riscv-gnu-toolchain, which means we no longer have to manually add them on top of the base source tree. For binutils, we now have only one local patch, for the CLIC support, and it is in there down below all of the other new stuff.

jim-wilson commented 5 years ago

Yes, the multilib list was updated to include all of the new multilibs.

kito-cheng commented 5 years ago

binutils: sifive-binutils-2.32 branch gcc: sifive-gcc-8.3.0 branch newlib: sifive-newlib-next branch (based on trunk)

jim-wilson commented 5 years ago

FYI Another problem with the Optimitech linker relaxation fix for c.lui has been reported. This is https://github.com/riscv/riscv-binutils-gdb/issues/173 I'm trying to reproduce.

kito-cheng commented 5 years ago

Included fix for riscv/riscv-binutils-gdb#173

cgsfv commented 5 years ago

Looks good to me.

@kito-cheng and @jim-wilson are we ready to go?

kito-cheng commented 5 years ago

Changes:

jim-wilson commented 5 years ago

I think it is good. We can always add more patches if something is missing or broken.

jim-wilson commented 5 years ago

I double checked, and I think this looks OK.

We are using FSF gdb. This means no gdb sim port as that isn't upstream yet. This is OK, as I think Kito and I are the only ones using it, and I haven't used it recently.

We are using sifive/riscv-qemu, and it looks like no one is maintaining that. There should be a plan to upgrade to upstream qemu at some point.

cgsfv commented 5 years ago

I am working on using qemu.org version 4.1.0 with a few minor updates, as it seems to work almost fine. Does this pose a problem with regards to GCC and Binutils?

jim-wilson commented 5 years ago

Qemu 4.1.0 should be fine.