Support PPC64? #554

rui314 · 2022-06-22T04:55:49Z

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.

marxin · 2022-09-12T07:49:08Z

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]       |  ^~~~~

rui314 · 2022-09-12T07:56:05Z

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

marxin · 2022-09-12T07:58:11Z

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?

rui314 · 2022-09-12T08:00:13Z

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.

marxin · 2022-09-12T08:21:54Z

Great, so for cda57cf 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!

#554

rui314 · 2022-09-12T08:28:19Z

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?

rui314 · 2022-09-12T08:29:21Z

Note that I'm pretty sure that mold won't work with -mcpu=power10, though.

marxin · 2022-09-12T08:36:56Z

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.

rui314 · 2022-09-12T08:47:22Z

Your binary works fine on qemu-ppc64le, so I'm not sure what's wrong. Maybe I need an access to a real machine.

rui314 · 2022-09-12T08:56:50Z

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.

marxin · 2022-09-12T08:59:05Z

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/

marxin · 2022-09-12T09:06:14Z

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.

rui314 · 2022-09-12T09:20:06Z

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?

marxin · 2022-09-12T09:24:06Z

Is s390x PPC64LE or something else?

No, It's IBM mainframe architecture:
https://en.wikipedia.org/wiki/IBM_Z

marxin · 2022-09-12T09:28:38Z

Your binary works fine on qemu-ppc64le, so I'm not sure what's wrong.

Same for me!

marxin · 2022-09-12T09:51:44Z

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

marxin · 2022-09-12T10:01:13Z

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.

On PPC64, page size is 65536 bytes or 0x10000 bytes. #554

rui314 · 2022-09-12T11:39:46Z

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?

marxin · 2022-09-12T13:39:31Z

It works! The wild one was the correct one.

marxin · 2022-09-12T13:40:33Z

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

marxin · 2022-09-12T20:09:47Z

No, It's IBM mainframe architecture: https://en.wikipedia.org/wiki/IBM_Z

There is an existing issue for that: #267.

glaubitz · 2022-09-27T22:24:13Z

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.

See: https://gcc.gnu.org/wiki/CompileFarm

rui314 · 2022-09-28T02:32:02Z

Yes, I already got an account for GCC compiler farm. Though there seems no s390x nor POWER10 machines available there.

marxin · 2022-09-28T07:05:11Z

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

glaubitz · 2022-09-28T07:12:42Z

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

rui314 · 2022-09-28T07:16:48Z

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.

marxin · 2022-10-09T12:24:34Z

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

glaubitz · 2022-10-09T12:39:35Z

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.

rui314 · 2022-10-10T02:42:46Z

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.

glaubitz · 2022-10-10T07:26:11Z

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

rui314 · 2022-10-10T08:02:05Z

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.

marxin · 2022-10-11T06:47:48Z

I can confirm all ppc64 tests are green! Kudos!

rui314 · 2022-10-11T07:05:00Z

Yes! Now we can close this bug.

rui314 added the enhancement New feature or request label Jun 22, 2022

rui314 mentioned this issue Jun 22, 2022

Distribute ARMv7, i386 and RV64 binaries #469

Open

rui314 added a commit that referenced this issue Sep 12, 2022

[ELF][PPC64] Handle R_PPC64_DTPREL64 against non-alloc sections

c0ff4a2

#554

rui314 added a commit that referenced this issue Sep 12, 2022

Make addresses given to --start-address multiples of 65536

b941a37

On PPC64, page size is 65536 bytes or 0x10000 bytes. #554

rui314 closed this as completed Oct 11, 2022

ericriff mentioned this issue May 16, 2023

Mips support #1040

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support PPC64? #554

Support PPC64? #554

rui314 commented Jun 22, 2022

marxin commented Sep 12, 2022

rui314 commented Sep 12, 2022

marxin commented Sep 12, 2022

rui314 commented Sep 12, 2022

marxin commented Sep 12, 2022 •

edited

rui314 commented Sep 12, 2022

rui314 commented Sep 12, 2022

marxin commented Sep 12, 2022

rui314 commented Sep 12, 2022

rui314 commented Sep 12, 2022

marxin commented Sep 12, 2022

marxin commented Sep 12, 2022

rui314 commented Sep 12, 2022

marxin commented Sep 12, 2022

marxin commented Sep 12, 2022

marxin commented Sep 12, 2022

marxin commented Sep 12, 2022

rui314 commented Sep 12, 2022

marxin commented Sep 12, 2022

marxin commented Sep 12, 2022

marxin commented Sep 12, 2022

glaubitz commented Sep 27, 2022

rui314 commented Sep 28, 2022

marxin commented Sep 28, 2022

glaubitz commented Sep 28, 2022 via email

rui314 commented Sep 28, 2022

marxin commented Oct 9, 2022

glaubitz commented Oct 9, 2022 via email

rui314 commented Oct 10, 2022

glaubitz commented Oct 10, 2022

rui314 commented Oct 10, 2022

marxin commented Oct 11, 2022

rui314 commented Oct 11, 2022

Support PPC64? #554

Support PPC64? #554

Comments

rui314 commented Jun 22, 2022

marxin commented Sep 12, 2022

rui314 commented Sep 12, 2022

marxin commented Sep 12, 2022

rui314 commented Sep 12, 2022

marxin commented Sep 12, 2022 • edited

rui314 commented Sep 12, 2022

rui314 commented Sep 12, 2022

marxin commented Sep 12, 2022

rui314 commented Sep 12, 2022

rui314 commented Sep 12, 2022

marxin commented Sep 12, 2022

marxin commented Sep 12, 2022

rui314 commented Sep 12, 2022

marxin commented Sep 12, 2022

marxin commented Sep 12, 2022

marxin commented Sep 12, 2022

marxin commented Sep 12, 2022

rui314 commented Sep 12, 2022

marxin commented Sep 12, 2022

marxin commented Sep 12, 2022

marxin commented Sep 12, 2022

glaubitz commented Sep 27, 2022

rui314 commented Sep 28, 2022

marxin commented Sep 28, 2022

glaubitz commented Sep 28, 2022 via email

rui314 commented Sep 28, 2022

marxin commented Oct 9, 2022

glaubitz commented Oct 9, 2022 via email

rui314 commented Oct 10, 2022

glaubitz commented Oct 10, 2022

rui314 commented Oct 10, 2022

marxin commented Oct 11, 2022

rui314 commented Oct 11, 2022

marxin commented Sep 12, 2022 •

edited