Fedora21/Loongnix 工具链升级

最近将龙芯中科、航天龙梦等单位的工具链补丁向社区较新版本(最新发现不稳定,已经计划修复)做了移植,并在龙梦版 Fedora21 上打包,同源的 Loongnix 应该也是可用的,现向社区用户开放同步测试。

版本信息:
binutils 2.29.1
gcc 5.5.0
gdb 8.0.1
glibc 2.26

软件源:
os: http://mirror.lemote.com/fedora/toolchain/os/

debug: http://mirror.lemote.com/fedora/toolchain/debug/

source: http://mirror.lemote.com/fedora/toolchain/source/

源代码:
binutils: https://github.com/loongson-co ... 9.1-2

gcc: https://github.com/loongson-co ... 5.0-1

gdb: https://github.com/loongson-co ... 0.1-1

29 个评论

我只求打到官方源代码上面的 patch 。
另外,GCC 7 现在什么情况?GCC 8 都不远了。别折腾旧版本了啊。
源代码已经托管在 github 上,GCC 7.x 编译是很容易的,也编译验证过,但有发现明显的bug暂不使用,先稳中求进吧,GCC 6.x 及之后已经在计划中。
-march=arch
Generate code that runs on arch, which can be the name of
a generic MIPS ISA, or the name of a particular processor.
The ISA names are: mips1, mips2, mips3, mips4, mips32,
mips32r2, mips32r3, mips32r5, mips32r6, mips64, mips64r2,
mips64r3, mips64r5 and mips64r6. The processor names are:
4kc, 4km, 4kp, 4ksc, 4kec, 4kem, 4kep, 4ksd, 5kc, 5kf,
20kc, 24kc, 24kf2_1, 24kf1_1, 24kec, 24kef2_1, 24kef1_1,
34kc, 34kf2_1, 34kf1_1, 34kn, 74kc, 74kf2_1, 74kf1_1,
74kf3_2, 1004kc, 1004kf2_1, 1004kf1_1, loongson2e,
loongson2f, loongson3a, m4k, m14k, m14kc, m14ke, m14kec,
octeon, octeon+, octeon2, octeon3, orion, p5600, r2000,
r3000, r3900, r4000, r4400, r4600, r4650, r4700, r6000,
r8000, rm7000, rm9000, r10000, r12000, r14000, r16000,
sb1, sr71000, vr4100, vr4111, vr4120, vr4130, vr4300,
vr5000, vr5400, vr5500, xlr and xlp. The special value
from-abi selects the most compatible architecture for the
selected ABI (that is, mips1 for 32-bit ABIs and mips3 for
64-bit ABIs).
什么时候把支持3A2000, 3A3000的合到上流中去呀
我要 patch 主要还是加进现有发行版的 srpm 里面,而不是替换源代码。
这样我可以尽可能保证和原版的统一。
至于 bug ……啥时候能让 bug 只出现在 dev 版里面,而不是 rel 版本里面呢?
heiher

heiher 回复 water

成熟、稳定的补丁一般都会向上游仓库提交的,已经错过提交窗口的版本只能先在 github 中托管、维护了。
说实话我也非常想呀 :)
龙芯开发多少年了。至少 bug 不能留下吧?
即便上游不收 loongson 相关的 patch ,至少 mips64r2 的应该会收吧?
现在我用 mips64r2 做优化参数,都遇到的问题,这解决起来,人家很乐意吧?
2018,加油吧
明日复明日,明日何其多……
当年我喷 o32 、当年我喷 n32 ,我不知道我是不是还会喷 n64 了。
我的 Gentoo gcc 7.2.0 一直没法 bootstrap,最近也没空看了。。。6.4.0 貌似能用,但 Loongnix java 二进制包直接崩溃,也没空调查
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
是这个问题吗?试试问题里的6楼的补丁。
666666 就是这个,有空搞一搞~
这个 bug 很神奇的,底下说没事了,但是依然存在。不知道怎么回事。
现在就是知道是 MIPS 后端做了一些神奇的事情。。。跟 x86、ARM 等后端行为不太一致,甚至在 MIPS 的不同变体下行为也不一致。然后这个优化 bug 会导致 gcc 本体被错误编译。。。我看所有人都一脸懵逼,gcc 底层我基本就没看过,只在移植补丁时候看过 MIPS 相关的一小段(笑
感觉 mips 这边就是补丁摞补丁的东西。神奇现象很正常。
嗯,变体太多了,尤其是 mips{32,64}{,el}, gnu{,abi64,abin32} 之后还有个 NUBI,历史包袱比 x86 还重。。。其实如果现在这个阶段换我来搞,极有可能就 loongson-unknown-linux-gnu 了,mkdir arch/loongson 了
一如 AArch64 那群人最后做出的选择,aarch64-unknown-linux-gnu,mkdir arch/arm64
你就别想进入主线了,你这等于是吧 mips 直接被你全否定了。
哎,AArch64 也不是全盘否定 ARM32。。。不过这就是另一回事了
aarch64 至少也算是个新的架构吧。
龙芯单独拿出来,这可不是一个新架构,mips64r2 架构的扩展可和 arm 指令集扩展 64 位不一样的概念。
啊,这反正就看以后 LoongISA 和龙芯对 MIPS 的实现会不会分道扬镳了。。。你说得有道理。
我觉得不能分啊,mips 带来的行业规范,还是很有用的。这对于市场推广很有用处。
emmmm,完全在 MIPS 话语体系里搞事情的话,那确实我们的 PR 要加把劲了。至少在 Imagination 不能扛起大旗的时候,我们要有人能以高标准严要求完成社区赋予的使命。我真心希望有生之年能看到支持 MIPS64r6 和 microMIPS 的龙芯。。。。。。
我倒是觉得 mips64r6 或者 micromips 倒不是关键,反而是龙芯能否吧现在的 r2 真正做好。在足够稳定的基础上做出扩展的高性能计算指令,这样在兼容上,既能保证一个稳定的指令集,在扩展上,又能有一个符合需要的提升。这样,在用户来说,只要能保证自己的软件兼容 mips64r2 ,就可以保证运行,又可以提供一个使用龙芯扩展指令的程序,提供高性能计算等等要求。
这样也不影响应用程序厂商的软件设计问题。
之后在某个阶段,再升级基础的 mips 指令集到 mips64r6 之后再稳定一段时间。
现在龙芯如果不能等软件应用环境稳定,就升级指令集,可能导致新版本的软件不能运行在老版本系统上,导致之前的硬件无法使用新软件而导致被迫废弃。
我觉得之前 mips3 64bit 升级到现在的 mips64r2 就有这个问题。
mips64r6移除了部分指令,能不能修改GCC让编译器尽量不生成这部分指令,用其它来代替!这样以后升到mips64r6时能尽可能兼容mips64r2编译的软件!
那不就等于是不兼容 mips64r2 了么?而且 mips64r6 也有增加的指令,等于是你这个目标两个都不兼容了。
两边都有损失,非常不值得。
不如保持 mips64r2 ,自己另作扩展指令实现 r6 的某些特性了。
没有不兼容啊,硬件还是要实现完整的mips64r2,但是软件编译的时候尽量不使用那些r6废器的指令!
不是尽量不使用,而是必须不使用。

要回复文章请先登录注册