GithubHelp home page GithubHelp logo

build-tools's People

Contributors

caiyinyu avatar chenhuacai avatar freeflyingsheep avatar gaosong-loongson avatar sunhaiyong1978 avatar theaoqi avatar yetist avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

build-tools's Issues

GNU上游工具链状态

GNU各工具链组合情况

上游工具链版本

上游binutils共5个release版本 2.38、2.39、2.40、2.41、2.42,1个开发版本master。
上游gcc共2个release版本 12.3.0、13.2.0,1个开发版本master。
上游glibc共4个release版本 2.36、2.37、2.38、2.39,1个开发版本master。

上游工具链搭配状态

1、测试流程为:

  • 编译安装各个版本的binutils。
  • 使用各个版本的binutils编译不依赖系统库的第一遍gcc。若某版本binutils无法编译gcc,则认为无法搭配。
  • 安装linux-6.8.4内核。
  • 使用各版本binutils和各版本第一遍gcc排列组合编译各版本glibc。
  • 使用上一步安装成功的工具链编译完整gcc。
  • 使用上述工具链编译运行spec2006 test,测试使用-march=loongarch64 -O2,不启用向量。

2、能够编译运行spec2006的组合如下表。
表中第1列表示binutils版本,第1行表示gcc版本,行和列的交点表示可以搭配的glibc版本。
测试结果表明,所有gcc版本和binutils 2.39-2.40版本搭配编译glibc2.36-2.38,所有gcc版本和binutils 2.41-2.42可以搭配所有glibc版本。

  • 其中binutils 2.39及以上版本可以编译第一遍gcc。binutils 2.38 使用lp64和ilp32两种ABI名称,gcc使用lp64d、lp64f、lp64s三种ABI名称,gcc传递的默认lp64d选项2.38版本汇编器不识别,因此无法搭配。
  • glibc2.39需要向量指令支持,binutils 2.41及以上版本加入向量指令。
binutils/glibc/gcc 12.3.0 13.2.0 master
2.38 × × ×
2.39 2.36/2.37/2.38 2.36/2.37/2.38 2.36/2.37/2.38
2.40 2.36/2.37/2.38 2.36/2.37/2.38 2.36/2.37/2.38
2.41 2.36/2.37/2.38/2.39/master 2.36/2.37/2.38/2.39/master 2.36/2.37/2.38/2.39/master
2.42 2.36/2.37/2.38/2.39/master 2.36/2.37/2.38/2.39/master 2.36/2.37/2.38/2.39/master
master 2.36/2.37/2.38/2.39/master 2.36/2.37/2.38/2.39/master 2.36/2.37/2.38/2.39/master

关于编译工具链的一些疑问

你好,我刚开始接触龙芯编译工具链,在使用loongarch64-linux-gnu-2021-06-19.tar.gz的时候遇到一些问题:
1、使用loongarch64-linux-gnu-gcc编译一个简单的c代码,发现编译出来的目标文件架构不对 ,是因为需要指定架构吗?
image

另外,可以提供关于这个工具链的使用文档吗?
谢谢!

Does ongoing CentOS 7 project for loongarch existing

Dear Loongson Community:

We are migrating python conda to loongarch64 (and maybe mips64), c.f. conda

Now an issue emerges, when porting conda-build, a Centos 7 repository seems to be required, like the code sample sections one for CPU arch IBM S390X:

S390X support

          'clefos': {'dirname': 'clefos',
                     'short_name': 'cos7',
                     'base_url': 'http://download.sinenomine.net/clefos/7/os/{base_architecture}/',  # noqa
                     'sbase_url': 'http://download.sinenomine.net/clefos/7/source/srpms/', # noqa
                     'repomd_url': 'http://download.sinenomine.net/clefos/7/os/repodata/repomd.xml', # noqa
                     'host_machine': '{gnu_architecture}-conda-cos7-linux-gnu',
                     'host_subdir': 'linux-s390x',
                     'fname_architecture': '{architecture}',
                     'rpm_filename_platform': 'el7.{architecture}',
                     'checksummer': hashlib.sha256,
                     'checksummer_name': "sha256",
                     'macros': {'pyver': '2.7.5',
                                'gdk_pixbuf_base_version': '2.36.2'}},

a loongarch64 version repository may be required to work with conda build. Now wondering, does anyone knows a working centos repository, or the CLFS tools here build-tool could be used to build one.

Many thanks,

Compile kernel and grub failed

Using either prebuild toolchain , or custom build toolchain from loongson repo(gcc-12 binutils-2.37 glibc-2.33)

/tmp/cc3MOy9W.s:537: Fatal error: no match insn: li $r12,0x4
{standard input}:887: Fatal error: no match insn: stl.w $r4,$r24,3

grub2
source https://github.com/loongarch64/grub/tree/dev-la64

In file included from ../../include/grub/relocator.h:25,
                 from ../../include/grub/loongarch64/relocator.h:24,
                 from ../../grub-core/lib/loongarch64/relocator.c:27:
../include/grub/cpu/memory.h: In function ‘grub_map_memory’:
../include/grub/cpu/memory.h:39:50: warning: unused parameter ‘size’ [-Wunused-parameter]
   39 | grub_map_memory (grub_phys_addr_t a, grub_size_t size)
      |                                      ~~~~~~~~~~~~^~~~
/tmp/cc3MOy9W.s: Assembler messages:
/tmp/cc3MOy9W.s:537: Fatal error: no match insn: li     $r12,0x4
Makefile:41604: recipe for target 'lib/loongarch64/relocator_module-relocator.o' failed

kernel
source https://github.com/loongson/linux/tree/loongarch-next

:~/mylaos/build/linux-5.13.0$ ARCH=loongarch CROSS_COMPILE=/home/lin/work/loongarch64-linux-gnu-2021-08-03/loongarch64-linux-gnu/bin/loongarch64-linux-gnu- make    
  CALL    scripts/checksyscalls.sh
  CALL    scripts/atomic/check-atomics.sh
  CHK     include/generated/compile.h
  CC      arch/loongarch/kernel/unaligned.o
{standard input}: Assembler messages:
{standard input}:887: Fatal error: no match insn: stl.w $r4,$r24,3
scripts/Makefile.build:272: recipe for target 'arch/loongarch/kernel/unaligned.o' failed
make[2]: *** [arch/loongarch/kernel/unaligned.o] Error 1
scripts/Makefile.build:515: recipe for target 'arch/loongarch/kernel' failed
make[1]: *** [arch/loongarch/kernel] Error 2
Makefile:1847: recipe for target 'arch/loongarch' failed
make: *** [arch/loongarch] Error 2

loongarch64-clfs-6.3-cross-tools-gcc-full.tar.xz格式错误

该压缩文件的格式是gzip而非xz,请更正压缩包的后缀,对使用者产生了严重误导导致无法正确解压缩。此外解压缩之后的文件夹名建议依然是loongarch64-clfs-6.3-cross-tools-gcc-full,目前是cross-tool,解压缩之后不容易找到。

clfs卡在random: crng init done

尝试在qemu7.1(win32/amd64)启动最新clfs镜像:

qemu-systrm-loongarch64.exe -m 1024 -smp 2 --cpu la464 --machine virt -bios QEMU_EFI.fd -drive file=loongarch64-clfs-system-6.3.qcow2,if=virtio -vga virtio

loongarch64-clfs-system-6.3.qcow2使用release中rootfs制作,QEMU_EFI.fd来自yangxiaojuan-loongson/qemu-binary
去掉grub中quiet选项启动,在较长时间后出现ramdom: crng init done并卡住
16652193272058071223784330354816

loongarch64-unknown-linux-gnu编译后能否在Loongson-3A4000上跑呢?

最近有一个法院的项目需要rust语言在x86 Ubuntu系统上跨平台交叉编译应用程序到Loongson-3A4000的笔记本电脑上。问一下编译loongarch64-unknown-linux-gnu能否在Loongson-3A4000上跑?
lscpu:
Architecture: mips64
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Model name: Loongson-3A R4 (Loongson-3A4000)

strange codegen for SIMD situations

so I tried several ways to hint the compiler to utilize SIMD extension, but the codegen is very funny:
Screenshot_20210725_215335
2
given that the instruction manual for the SIMD extension is still not open for us, I would like to ask will such extensions be made public for all developers finally?

建议 README 链接到 loongson 组织下的仓库

目前 README 中下载地址链接到了其他用户名下的仓库(目测是贵司的员工),但考虑到已经有 loongson 组织的官方仓库,建议将相关仓库挪到 loongson 组织下,这样比较正式,否则在外人看来,就会觉得贵司的开发和权限管理出现了割裂。

loongarch64-clfs-system-2021-12-02在LM3a5000上起不来

kernel 载入后键盘灯闪一下卡死
拿掉 acpi_initrd 也起不来
启动参数带 verbose ignore_loglevel 也没提示
接上串口 consoleblank=0 earlyprintk=ttyS0 console=ttyS0 nomodeset 串口也没信息

主板:LM-LS3A5000-7A1000-1w-V01-pc_A2101
固件:
Vendor: ZD-TECH
Version: KL.4.1H.LM.D.025.211109.R
Release Date: 11/09/2021
ROM Size: 8192 kB

Alignment of struct sigcontext

在最新的内核代码中,struct sigcontext 的对齐由 32 降为了 16:https://github.com/loongson/linux/blob/loongarch-next/arch/loongarch/include/uapi/asm/sigcontext.h#L24

内核里面的 struct ucontext 最后一个字段是 struct sigcontext,但是 glibc 里面的 struct ucontext 最后一个字段是 mcontext_t,后者仍然是 32 字节对齐。这导致内核与 glibc 的 struct ucontext 布局不一样,而 libgcc 里面又有一个

      struct rt_sigframe
      {   
        siginfo_t info;
        ucontext_t uc;
      } *rt_ = context->cfa;

这里 ucontext_t 是 glibc 的 struct ucontext,结果 rt_sigframe 的结构和内核不一样了。然后用到 libgcc unwinder 的程序会在这里挂掉。

因为内核那边没开 Issues,报到这里了。

建议提供exe格式的qemu程序

主机需要常时跑windows干活,目前靠wsl和虚拟机提供linux环境,主机性能有限不足以在虚拟机中跑qemu,wsl还没试过,估计也够呛(而且不是标准linux内核),希望能编译一个windows nt x64环境下原生运行的环境用来测试

关于qemu搭配debootstrap使用的问题

Hi

我想用qemu搭一个loongnix的最小系统,以便chroot进去编译我的程序,避免交叉编译的一些麻烦。

步骤:

  1. debootstrap --no-check-gpg --variant=minbase --components=main,non-free,contrib --arch=loongarch64 --foreign DaoXiangHu-stable rootfs-loongarch64 http://pkg.loongnix.cn/loongnix/
  2. 使用https://github.com/loongson/build-tools/releases/download/2022.05.29/qemu-loongarch64 这版,然后配置好binfmt
  3. sudo chroot rootfs-loongarch64 /debootstrap/debootstrap --second-stage

此时报错/bin/sh: error while loading shared libraries: libc.so.6: cannot stat shared object: Error 38

测试环境为Ubuntu 20.04 amd64

有看到这个issue:#18 ,但他最后的解法是换工具链,而我是想用loongnix的官方源。

感谢!

gcc 编译器问题 internal compiler error: in output_constructor_regular_field, at varasm.c:5512

github.com/loongson/gcc 的loongarch-12分支
编译 poppler时,会出错

 g++ poppler_Decrypt_preprocessed.cc -c
/var/tmp/portage/app-text/poppler-21.12.0/work/poppler-21.12.0/poppler/Decrypt.cc:1826:1: 编译器内部错误:在 output_constructor_regular_field 中,于 varasm.c:5512
 1826 | }
      | ^
0x1134277 internal_error(char const*, ...)
        ???:0
0x1a2887 fancy_abort(char const*, int, char const*)
        ???:0
0xbdecbf assemble_variable(tree_node*, int, int, int)
        ???:0
0xbe24ab varpool_node::assemble_decl()
        ???:0
0x4c2067 symbol_table::finalize_compilation_unit()
        ???:0
请提交一份完整的错误报告,
如有可能请附上经预处理后的源文件。
Please include the complete backtrace with any bug report.
参阅 <https://bugs.gentoo.org/> 以获取指示。

使用clfs原生工具链,也类似

/opt/clfs/usr/bin/g++ poppler_Decrypt_preprocessed.cc -c 
/var/tmp/portage/app-text/poppler-21.12.0/work/poppler-21.12.0/poppler/Decrypt.cc:1826:1: internal compiler error: in output_constructor_regular_field, at varasm.c:5512
 1826 | }
      | ^
0x12110ad07 internal_error(char const*, ...)
        ???:0
0x1201b4aff fancy_abort(char const*, int, char const*)
        ???:0
0x120bccb07 assemble_variable(tree_node*, int, int, int)
        ???:0
0x120bd0223 varpool_node::assemble_decl()
        ???:0
0x1204d4b23 symbol_table::finalize_compilation_unit()
        ???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

使用clfs cross工具链,则无问题

llvm 则基本一致
使用loongarch工具链有问题,clfs la原生工具链有问题
使用gcc 11 x86编译无问题,clfs cross工具链无问题
使用loongarch源码编译的 x86_64 g++则有同样问题

gcc bugzilla有类似报告,不过看起来不像是同一个问题
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102434

llvm

请问有可以公开的 LLVM 源码吗?今天看新闻说龙芯的工程师已经用 clang 编译虚幻引擎了。

主要是 rustc 需要 LLVM,如果 LLVM 弄好的话 rustc 我看了一下应该写几百行 (?) 代码描述一些机器特性就行。

如果没有的话我可能去试着玩玩 gccrs 或者 rustc 的 libgccjit backend……

建议公开GCC源代码

首先感谢龙芯社区开发者的积极付出,让LoongArch这一新平台也有了属于自己的GCC,为开源社区的持续发展打下了坚实基础。

考虑到GCC是基于GPL的自由软件,原则上需要公布修改后的源代码;并且为新架构提供支持,本身就是值得反馈给GNU上游的巨大贡献(龙芯MIPS架构支持已经是GNU官方源码的一部分)。

因此建议龙芯社区团队在此发布源代码,而不仅仅是二进制版本。这样能让更多开发者作出贡献,开启更多新可能。

如何生成 loongarch 的 32bit 代码

我使用 loongarch64-clfs-20210812-cross-tools ,想要生成 32bit 的目标代码。

试过
loongarch64-unknown-linux-gnu-gcc -march=loongarch32 a.c
loongarch64-unknown-linux-gnu-gcc: error: unrecognized argument in option ‘-march=loongarch32’

The build tool url address changed

Hi @FreeFlyingSheep . I found the qemu tool address has been changed. And the address in readme does not have .bin extension.
https://github.com/loongson/build-tools/blame/750aa562ae8a2a943c06829322bc5862c89ee11e/README.md#L23

Old url : https://github.com/loongson/build-tools/releases/download/2022.09.06/qemu-loongarch64
New url: https://github.com/loongson/build-tools/releases/download/2022.09.06/qemu-loongarch64.bin

This change break my ci action. Can you keep the file address unchanged? Thanks a lot.

centos 8编译loongarch64 UEFI 固件

参考https://github.com/foxsen/edk2-platforms/blob/devel-LoongArch/Platform/Loongson/LoongArchQemuPkg/Readme.md的步骤,遇到这个错误
loongarch64-linux-gnu-gcc: error: unrecognized command line option '-mno-explicit-relocs'; did you mean '-fno-implicit-none'?
当前gcc是这个版本
sing built-in specs.
COLLECT_GCC=loongarch64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/opt/loongson-gnu-toolchain-8.3-x86_64-loongarch64-linux-gnu-rc1.1/bin/../libexec/gcc/loongarch64-linux-gnu/8.3.0/lto-wrapper
Target: loongarch64-linux-gnu
Configured with: /dev/shm/build_loongarch64_gcc8-host-x86_64-rc1.1_2022-09-14/src/gcc/configure --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=loongarch64-linux-gnu --program-prefix=loongarch64-linux-gnu- --prefix=/dev/shm/build_loongarch64_gcc8-host-x86_64-rc1.1_2022-09-14/cross --libdir=/dev/shm/build_loongarch64_gcc8-host-x86_64-rc1.1_2022-09-14/cross/lib --with-gxx-include-dir=/dev/shm/build_loongarch64_gcc8-host-x86_64-rc1.1_2022-09-14/cross/sysroot/usr/include/c++ --with-sysroot=/dev/shm/build_loongarch64_gcc8-host-x86_64-rc1.1_2022-09-14/cross/sysroot --with-native-system-header-dir=/usr/include --with-slibdir=/dev/shm/build_loongarch64_gcc8-host-x86_64-rc1.1_2022-09-14/cross/sysroot/usr/lib --with-pkgversion='LoongArch GNU toolchain rc1.1 (20220914)' --with-arch=loongarch64 --with-abi=lp64d --with-multilib-list=lp64d,lp64s --enable-checking=release --disable-linker-build-id --enable-languages=c,c++,fortran --disable-libgcc --disable-libstdc++ --disable-libgfortran --disable-gcov --enable-libcc1 --enable-threads=posix --enable-tls --enable-initfini-array --enable-__cxa_atexit --disable-libatomic --disable-libmudflap --disable-libvtv --disable-libgomp --disable-libmpx --disable-nls --disable-bootstrap
Thread model: posix
gcc version 8.3.0 (LoongArch GNU toolchain rc1.1 (20220914))
请问是否当前gcc不支持该命令参数?

Release tar files have incorrect file extension

Some toolchain tarballs from the Releases Download section have incorrect file extensions.

They claim to be .tar.xz files, but in fact these were compressed with gzip instead and should carry the .tar.gz extension.

For example https://github.com/loongson/build-tools/releases/download/2022.09.06/loongarch64-clfs-6.3-cross-tools-gcc-full.tar.xz:

Extracting it as xz files does not work:

$ tar xJf ./loongarch64-clfs-6.3-cross-tools-gcc-full.tar.xz                                               
xz: (stdin): File format not recognized
tar: Child returned status 1
tar: Error is not recoverable: exiting now

Here we see that this is in fact a gzip file:

$ file ./loongarch64-clfs-6.3-cross-tools-gcc-full.tar.xz                                                  
./loongarch64-clfs-6.3-cross-tools-gcc-full.tar.xz: gzip compressed data, from Unix, original size modulo 2^32 3332720640

Extracting with the options for gzip works:

$ tar xzvf ./loongarch64-clfs-6.3-cross-tools-gcc-full.tar.xz                                            
cross-tools/
cross-tools/share/
cross-tools/share/locale/
cross-tools/share/locale/da/
cross-tools/share/locale/da/LC_MESSAGES/
[...]

动态链接出现问题?

我们使用 loongarch64-clfs-2022-03-03-cross-tools-gcc_and_clang-full.tar.xz 工具链,在 Debian Linux x86_64 上编译以下源代码:

#include <stdio.h>
int main(void) {
        printf("Hello LoongArch!\n");
        return 0;
}

使用的编译指令为:

clang --target=loongarch64-unknown-linux-gnu hw.c -o hw

由于 Debian 上没有安装过 LLVM,所以可以确定使用的就是工具链的 clang。

将编译生成的二进制文件上传到 Loongnix-Server Linux 8 loongarch64 的机器上无法运行,提示:

-bash: ./hw: No such file or directory


再使用

clang --target=loongarch64-unknown-linux-gnu hw.c -static -o hw

在同样的龙芯机器上可以正常运行,故怀疑动态链接存在问题?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.