Closed rui314 closed 1 year ago
Btw. is the target at least partially supported?
I still see:
[ 58s] c++ -std=c++20 -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -DMOLD_VERSION=\"1.4.2\" -DLIBDIR="\"/usr/lib64\"" -MT out/demangle.o -MMD -MP -MF out/demangle.d -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -g -Wno-sign-compare -c -o out/demangle.o demangle.cc
[ 58s] In file included from mold.h:3,
[ 58s] from demangle.cc:1:
[ 58s] inttypes.h:28:2: error: #error "mold does not support big-endian hosts"
[ 58s] 28 | #error "mold does not support big-endian hosts"
[ 58s] | ^~~~~
Our implementation supports only little-endian PPC64 system with the ELFv2 ABI as a target. It looks like you are trying to build mold on a big-endian PPC machine. That's not a supported host (and not a supported target as well).
Yeah, I noticed your recent commits that were prefixed as PPC64
. It may be better to prefix them with PPC64LE
;) Are you interested in test-result on ppc64le
system I have?
Oh, sure, if you have one, please share it with me. I don't have a PPC box, so it's just tested with QEMU user-mode emulator. I'm curious if it actually works on a real system.
Great, so for cda57cfe4a8107dc4d188b8057a72a31cafef6d4 I see:
...
Testing filler ... mold: fatal: /usr/lib64/libc.a(errno.o):(.debug_info): apply_reloc_nonalloc: R_PPC64_DTPREL64
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:211: test/elf/filler.sh] Error 1
...
Testing exception ... mold: fatal: /usr/lib64/gcc/powerpc64le-suse-linux/12/libstdc++.a(eh_globals.o):(.debug_info): apply_reloc_nonalloc: R_PPC64_DTPREL64
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:211: test/elf/exception.sh] Error 1
...
Testing hello-static ... mold: fatal: /usr/lib64/libc.a(errno.o):(.debug_info): apply_reloc_nonalloc: R_PPC64_DTPREL64
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:211: test/elf/hello-static.sh] Error 1
...
Testing ifunc-static ... mold: fatal: /usr/lib64/libc.a(errno.o):(.debug_info): apply_reloc_nonalloc: R_PPC64_DTPREL64
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:211: test/elf/ifunc-static.sh] Error 1
...
Testing omagic ... mold: fatal: /usr/lib64/libc.a(errno.o):(.debug_info): apply_reloc_nonalloc: R_PPC64_DTPREL64
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:211: test/elf/omagic.sh] Error 1
...
Testing section-start ... make[1]: *** [Makefile:211: test/elf/section-start.sh] Error 1
Where section-start
fails due to a crash during start:
valgrind out/test/elf/ppc64le/section-start/exe
==31699== Memcheck, a memory error detector
==31699== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==31699== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==31699== Command: out/test/elf/ppc64le/section-start/exe
==31699==
--31699-- WARNING: Serious error when reading debug info
--31699-- When reading debug info from /home/abuild/rpmbuild/BUILD/mold-1.999.999+git.20220912.cda57cfe/out/test/elf/ppc64le/section-start/exe:
--31699-- Can't make sense of .plt section mapping
==31699== Invalid read of size 8
==31699== at 0x40395E8: dl_main (in /usr/lib64/ld64.so.2)
==31699== by 0x403488F: _dl_sysdep_start (in /usr/lib64/ld64.so.2)
==31699== by 0x4036397: _dl_start_final (in /usr/lib64/ld64.so.2)
==31699== by 0x4036FC7: _dl_start (in /usr/lib64/ld64.so.2)
==31699== by 0x4035657: (below main) (in /usr/lib64/ld64.so.2)
==31699== Address 0x8 is not stack'd, malloc'd or (recently) free'd
==31699==
==31699==
==31699== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==31699== Access not within mapped region at address 0x8
==31699== at 0x40395E8: dl_main (in /usr/lib64/ld64.so.2)
==31699== by 0x403488F: _dl_sysdep_start (in /usr/lib64/ld64.so.2)
==31699== by 0x4036397: _dl_start_final (in /usr/lib64/ld64.so.2)
==31699== by 0x4036FC7: _dl_start (in /usr/lib64/ld64.so.2)
==31699== by 0x4035657: (below main) (in /usr/lib64/ld64.so.2)
==31699== If you believe this happened as a result of a stack
==31699== overflow in your program's main thread (unlikely but
==31699== possible), you can try to increase the size of the
==31699== main thread stack using the --main-stacksize= flag.
==31699== The main thread stack size used in this run was 8388608.
Apart from that, all tests are green!
That's great news!
I think I can fix the first issue easily. The second valgrind issue is a bit mysterious. Can you share that executable valgrind is complaining with me?
Note that I'm pretty sure that mold won't work with -mcpu=power10
, though.
I think I can fix the first issue easily. The second valgrind issue is a bit mysterious. Can you share that executable valgrind is complaining with me?
Sure: section-start.tar.gz
Note my GCC compiler is configured as:
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,ada,go,jit --enable-host-shared --enable-checking=release --disable-werror --with-gxx-include-dir=/usr/include/c++/12 --enable-ssp --disable-libssp --disable-libvtv --enable-cet=auto --disable-libcc1 --enable-plugin --with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --with-gcc-major-version-only --enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function --program-suffix=-12 --without-system-libunwind --with-cpu=power8 --with-tune=power9 --with-long-double-format=ieee --enable-secureplt --with-long-double-128 --enable-targets=powerpcle-linux --disable-multilib --with-build-config=bootstrap-lto-lean --enable-link-mutex --build=powerpc64le-suse-linux --host=powerpc64le-suse-linux
So --with-cpu=power8 --with-tune=power9
.
Your binary works fine on qemu-ppc64le, so I'm not sure what's wrong. Maybe I need an access to a real machine.
But still that is a quite good result. It took less than a week for me to get to this point!
By the way, do you think mold's multi-target support is good enough? I believe with PPC64LE, we've covered almost all modern systems. It looks like SPARC has been discontinued. MIPS is probably being replaced by RISC-V. Alpha and Itanium have died out. We don't need to support all living targets, but we aim to support a reasonable set of target machines.
Maybe I need an access to a real machine.
You should definitely create an account for GCC Compiler Farm: https://gcc.gnu.org/wiki/CompileFarm https://cfarm.tetaneutral.net/users/new/
Where we have a rich variety of machines: https://cfarm.tetaneutral.net/machines/list/
By the way, do you think mold's multi-target support is good enough?
From SUSE
and openSUSE
perspectives it's good. Right now, we do support x86_64
, aarch64
, 'ppc64le' and s390x
for SLE and openSUSE
adds support for i586
, ARM 32-bit targets (2 flavors), riscv64
. We do also somehow support ppc
and ppc64
, but there are not much supported and are not practically used.
Thanks, I requested an account for GCC Compiler Farm.
From SUSE and openSUSE perspectives it's good. Right now, we do support x86_64, aarch64, 'ppc64le' and s390x for SLE and openSUSE adds support for i586, ARM 32-bit targets (2 flavors), riscv64. We do also somehow support ppc and ppc64, but there are not much supported and are not practically used.
Is s390x PPC64LE or something else?
Is s390x PPC64LE or something else?
No, It's IBM mainframe architecture: https://en.wikipedia.org/wiki/IBM_Z
Your binary works fine on qemu-ppc64le, so I'm not sure what's wrong.
Same for me!
So the remaining issue is somehow caused by debug info, because:
$ strip out/test/elf/ppc64le/section-start/exe
$ out/test/elf/ppc64le/section-start/exe
Hello world
and objdump -D
complains:
objdump -D out/test/elf/ppc64le/section-start/exe 2>&1 | grep -U5 'is out'
2003ec: 47 4c 49 42 bcla 18,4*cr2+gt,4c44 <_GLOBAL_OFFSET_TABLE_+0x4c44>
2003f0: 43 5f 32 2e cmpdi cr4,r18,24387
2003f4: 31 37 00 47 .long 0x47003731
2003f8: 4c 49 42 43 bc- 26,eq,204d44 <__abi_tag+0x4a2c>
2003fc: 5f 32 2e 33 addic r25,r14,12895
200400: Address 0x0000000000200400 is out of bounds.
Disassembly of section .gnu.version:
0000000000200402 <.gnu.version>:
200402: 00 00 03 00 .long 0x30000
200406: Address 0x0000000000200406 is out of bounds.
Disassembly of section .gnu.version_r:
0000000000200408 <.gnu.version_r>:
--
64: 6d 70 61 74 andis. r1,r3,28781
68: 69 62 6c 65 oris r12,r11,25193
6c: 20 77 69 74 andis. r9,r3,30496
70: 68 20 47 4e .long 0x4e472068
74: 55 20 6c 64 oris r12,r3,8277
78: Address 0x0000000000000078 is out of bounds.
Disassembly of section .debug_abbrev:
0000000000000000 <.debug_abbrev>:
--
1a8: 13 05 00 00 .long 0x513
1ac: 00 01 11 00 .long 0x110100
1b0: 10 17 55 17 .long 0x17551710
1b4: 03 0e 1b 0e twlti r27,3587
1b8: 25 0e 13 05 .long 0x5130e25
1bc: Address 0x00000000000001bc is out of bounds.
Disassembly of section .debug_aranges:
0000000000000000 <.debug_aranges>:
--
580: 07 02 00 00 .long 0x207
584: 2d 00 00 00 .long 0x2d
588: 8b 05 00 00 .long 0x58b
58c: 6a 04 00 00 .long 0x46a
590: 1b 00 00 00 .long 0x1b
594: Address 0x0000000000000594 is out of bounds.
Disassembly of section .debug_line:
0000000000000000 <.debug_line>:
--
258: 09 02 58 00 .long 0x580209
25c: 21 00 00 00 .long 0x21
260: 00 00 03 2f cmpwi cr6,r3,0
264: 01 21 21 21 subfic r9,r1,8449
268: 02 01 00 01 .long 0x1000102
26c: Address 0x000000000000026c is out of bounds.
Disassembly of section .debug_line_str:
0000000000000000 <.debug_line_str>:
--
48: 63 72 74 69 xori r20,r11,29283
4c: 2e 53 00 63 ori r0,r24,21294
50: 72 74 6e 2e cmpdi cr4,r14,29810
54: 53 00 73 74 andis. r19,r3,83
58: 61 72 74 2e cmpdi cr4,r20,29281
5c: Address 0x000000000000005c is out of bounds.
Disassembly of section .debug_rnglists:
0000000000000000 <.debug_rnglists>:
--
2c: 00 07 94 00 .long 0x940700
30: 21 00 00 00 .long 0x21
34: 00 00 10 07 .long 0x7100000
38: 58 00 21 00 .long 0x210058
3c: 00 00 00 00 .long 0x0
40: Address 0x0000000000000040 is out of bounds.
Disassembly of section .debug_str:
0000000000000000 <.debug_str>:
--
598: 77 65 72 70 andi. r18,r3,25975
59c: 63 2f 70 6f xoris r16,r27,12131
5a0: 77 65 72 70 andi. r18,r3,25975
5a4: 63 36 34 2f cmpdi cr6,r20,13923
5a8: 63 72 74 6e xoris r20,r19,29283
5ac: Address 0x00000000000005ac is out of bounds.
My wild guess is that we need to pass a multiple of the page size as an argument for --start-address
. Since PPC64LE's page size is 0x10000, section start addresses weren't aligned to page boundaries. I modified the test. Can you try again?
It works! The wild one was the correct one.
Btw. you can watch the build of the nightly updated mold
package in OBS here:
https://build.opensuse.org/package/show/home:marxin:branches:devel:tools:compiler/mold
No, It's IBM mainframe architecture: https://en.wikipedia.org/wiki/IBM_Z
There is an existing issue for that: #267.
Oh, sure, if you have one, please share it with me. I don't have a PPC box, so it's just tested with QEMU user-mode emulator. I'm curious if it actually works on a real system.
FWIW, you can access real machines from various architectures through the GCC compile farm. No need to use QEMU.
Yes, I already got an account for GCC compiler farm. Though there seems no s390x nor POWER10 machines available there.
@rui314 Still no access to any of these 2 targets? If so, I can directly ask IBM folks involved in the GCC community for machine access. Will you be interested?
@rui314 Still no access to any of these 2 targets? If so, I can directly ask IBM folks involved in the GCC community for machine access. Will you be interested?Indeed. IBM is very helpful in this regard and they are usually very quick in providing access to the requested architectures.You can also ask OSUOSL whether they already have POWER10 machines available.See:Â https://osuosl.org/services/powerdev/request_hosting/FWIW, gcc203, the big-endian ppc64 machine in the GCC compile farm will soon return to service. It has been offline because it was moved to a different server room.
I still don't have access to neither s390x nor POWER10. I'll appreciate if you can ask for IBM folks to help on this.
I've just added OBS ppc64
target, you can take a look at the current test suite success rate:
https://build.opensuse.org/package/show/home:marxin:mold/mold
I've just added OBS ppc64 target, you can take a look at the current test suite success rate: https://build.opensuse.org/package/show/home:marxin:mold/mold
mold is also being built on many architectures in Debian and with the latest version, mold builds on sparc64 now: \o/
https://buildd.debian.org/status/package.php?p=mold&suite=sid
If there is any interest for access to any of the above targets, let me know.
I have fast MIPS64EL machines available, for example. But also ppc64, sh4, ia64 etc.
If there is any interest for access to any of the above targets, let me know.
I have fast MIPS64EL machines available, for example. But also ppc64, sh4, ia64 etc.
Thanks. I don't need an access to these machines for now, but I may in the future.
Speaking of MIPS, MIPS is probably the trickiest target to support. It's not because of its ISA but because of its psABI. It looks like Sillicon Graphics made lots of extensions to their own ELF implementation and then the extensions were kind of abandoned after MIPS SGI workstations were replaced with Windows NT-based graphics workstations. As a result, MIPS ELF even today still has many odd extensions, and most of them are not really documented. I don't exactly know what to do to support MIPS. I also don't know what is the "right level of support" of ELF MIPS; I don't think we need to support all of them, but since I have no knowledge about real MIPS systems, I can't decide what extensions are needed.
So unless there's a strong commercial interest in it, it is unlikely that mold will support MIPS ELF.
The company behind the LoongArch (a MIPS derivative) architecture, Loongson, is investing a lot of efforts to port as much FOSS software to the architecture. So I think it's quite likely that they will send you patches in the near future to add support for LoongArch.
Btw, would you also be willing to add architecture support on request if the community was sponsoring it? I would be interested in M68k support which is supported by LLVM as well. Adding M68k support to LLVM was supported through a BountySource campaign and I think we could gather money for support in Mold as well ;).
I hope LoongArch guys wanted to pay me instead to make me support their platforms 😎
I'm open to community-sponsored funding. I don't know how hard/easy it is to support m68k, but with funding I can raise the priority. At the moment, I'm working hard to make my company profitable (I'm still losing my money), so I don't have enough time to work on retro computers.
I can confirm all ppc64
tests are green! Kudos!
Yes! Now we can close this bug.
We may want to support PPC64 ELF v2 ABI (https://github.com/inconstante/ELFv2-ABI). I don't know if there's a need for it though.