problem compiling for 32bit powerpc targets

[uucidl]

Given the file minimal.c

int main(int argc, char** argv)
{ return 42; }

Which compiles succesfully on the host (windows x86_64)

H:\zig_on_ppc>zig build-exe --c-source minimal.c --library c
H:\zig_on_ppc>

When attempting the same for a 32bit power pc target, we encounter immediately an error:

H:\zig_on_ppc>zig build-exe --c-source minimal.c --library c -target powerpc-linux-gnu

H:\\3rdparty\\zig-windows-x86_64-0.4.0\\lib\\zig\\libunwind\\src\\UnwindRegistersRestore.S:398:46: error: unexpected token in directive
.globl _ZN9libunwind13Registers_ppc6jumptoEv @ .hidden _ZN9libunwind13Registers_ppc6jumptoEv @ .type _ZN9libunwind13Registers_ppc6jumptoEv,@function @ _ZN9libunwind13Registers_ppc6jumptoEv:
                                             ^
H:\\3rdparty\\zig-windows-x86_64-0.4.0\\lib\\zig\\libunwind\\src\\UnwindRegistersRestore.S:400:17: error: unexpected token
; void libunwind::Registers_ppc::jumpto()
                ^
H:\\3rdparty\\zig-windows-x86_64-0.4.0\\lib\\zig\\libunwind\\src\\UnwindRegistersRestore.S:402:11: error: unexpected token
; On entry:
          ^
H:\\3rdparty\\zig-windows-x86_64-0.4.0\\lib\\zig\\libunwind\\src\\UnwindRegistersRestore.S:403:24: error: unexpected token
; thread_state pointer is in r3
                       ^
H:\\3rdparty\\zig-windows-x86_64-0.4.0\\lib\\zig\\libunwind\\src\\UnwindRegistersRestore.S:406:22: error: unexpected token
  ; restore integral registerrs
                     ^
H:\\3rdparty\\zig-windows-x86_64-0.4.0\\lib\\zig\\libunwind\\src\\UnwindRegistersRestore.S:407:13: error: unexpected token
  ; skip r0 for now
            ^
(... abbreviated ...)

H:\\3rdparty\\zig-windows-x86_64-0.4.0\\lib\\zig\\libunwind\\src\\UnwindRegistersRestore.S:558:13: error: invalid memory operand
  lwz r3,20(r3) ; do r3 last
            ^
H:\\3rdparty\\zig-windows-x86_64-0.4.0\\lib\\zig\\libunwind\\src\\UnwindRegistersRestore.S:558:25: error: unexpected token
  lwz r3,20(r3) ; do r3 last
                        ^

The following command failed:
H:\3rdparty\zig-windows-x86_64-0.4.0\zig.exe cc -MD -MV -MF C:\Users\Nicolas\AppData\Local\zig\stage1\tmp\TPBbmNsmEzfx-UnwindRegistersRestore.o.d -nostdinc -fno-spell-checking -isystem H:\3rdparty\zig-windows-x86_64-0.4.0\lib\zig\include -isystem H:\3rdparty\zig-windows-x86_64-0.4.0\lib\zig\libc\include\powerpc-linux-gnu -isystem H:\3rdparty\zig-windows-x86_64-0.4.0\lib\zig\libc\include\generic-glibc -isystem H:\3rdparty\zig-windows-x86_64-0.4.0\lib\zig\libc\include\powerpc-linux-any -isystem H:\3rdparty\zig-windows-x86_64-0.4.0\lib\zig\libc\include\any-linux-any -target powerpc-unknown-linux-gnu -g -fstack-protector-strong --param ssp-buffer-size=4 -fno-omit-frame-pointer -o C:\Users\Nicolas\AppData\Local\zig\stage1\tmp\TPBbmNsmEzfx-UnwindRegistersRestore.o -c H:\3rdparty\zig-windows-x86_64-0.4.0\lib\zig\libunwind\src\UnwindRegistersRestore.S -fPIC -I H:\3rdparty\zig-windows-x86_64-0.4.0\lib\zig\libunwind\include -fPIC -D_LIBUNWIND_DISABLE_VISIBILITY_ANNOTATIONS -D_DEBUG

I looked afterwards at H:\3rdparty\zig-windows-x86_64-0.4.0\lib\zig\libunwind\src\UnwindRegistersRestore.S and I think this file's __ppc__ block is using syntax that clang's CC does not expect.

When I change all ; (comments) to // and all register names from r0 to %r0 ; f0 to %f0 etc.. then I get libunwind to compile. However this indicates something's already wrong upstream with libunwind.

After doing this, I encountered next a linking error in the case of powerpc-linux-gnu and in the case of powerpc-linux-musl a problem with the definition of the long doubles : musl seems to expect them to have a mantissa of 53 bits where clang apparently uses way larger doubles on ppc.

[andrewrk]

Thanks for taking the time to file this issue.

I'm guessing nobody has ever tested building libunwind for powerpc32 with Clang. I'm sure upstream would appreciate a patch to fix it, given that the libunwind sources come from the LLVM project.

As for musl, I wonder if perhaps Zig is failing to set some C define that musl expects to have set? Otherwise, we should work with the musl community; it's a very active and friendly project.

[uucidl]

The musl defines are hardcoded in float.h [1] and I suspect work with a gcc compiler. Clang may be using different long double sizes than gnu. I've investigated it further by defining musl's long double constants to the internal ones that clang exports (such as LDBL_MANT_DIG) ; at that point musl said it wasn't a supported long double size.

[1] float.h being: zig-windows-x86_64-0.4.0/lib/zig/libc/musl/arch/powerpc/bits/float.h

I have seen 32bit powerpc support dwindle, I suspect it's not a terribly attractive target for most projects. The reason I'm interested in it is that I happen to own a NAS that runs on that ISA and was looking to be able to compile to it. I also suspected that nobody had really tested libunwind in a while on ppc.. This makes it hard to be confident even upstreaming a patch, without the safety of having other people trying it.

[uucidl]

I've looked around in the bug database for llvm to see if there are more context around this:

• https://bugs.llvm.org/show_bug.cgi?id=31590 (mentions powerpc64 and powerpc) someone reporting in 2017 the same issue that I encountered with assembly syntax being incorrect.

The powerpc64 backend for libunwind seems to be much newer (from last year), and the ppc one (32bit) seems to come from when the Macos platform was running on powerpc. (~2013)

Also libunwind's index.rst does not mention any powerpc platform.

[LemonBoy]

This problem is fixed in the latest libunwind, yay!

[nektro]

have the changes from ^ been merged? If I try building using the current master I get the following:

❯ zig build-exe main.c -l c -target powerpc-linux-gnu
error(compilation): clang failed with stderr: In file included from /home/sappho/.local/lib/zig/lib/zig/libc/glibc/sysdeps/powerpc/powerpc32/crti.S:42:
/home/sappho/.local/lib/zig/lib/zig/libc/glibc/sysdeps/unix/sysv/linux/powerpc/powerpc32/sysdep.h:21:10: fatal error: 'sysdeps/unix/sysv/linux/powerpc/sysdep.h' file not found

[LemonBoy]

have the changes from ^ been merged?

Yes, this ticket can be closed.

If I try building using the current master I get the following

PPC32 is tier3, some bits and pieces are missing.

[uucidl]

please close the issue if you think it's fixed.

Apologies if the following is slightly inaccurate, as I haven't updated my version of zig in a while nor tried recently:

As a potential user of zig, I'm confused by the support tiers. They seem to be an internal management concept for the zig project, rather than a tool for users to know quickly whether they can use zig to target a particular platform.

By which I mean, I'd prefer if the support table left out all the tier3 and tier4 platforms and moved them to a separate table, because they're effectively not usable.

Edit:
And I say this because at the time I really distinctively thought that zig advertising such a wide range of supported platforms was kind of false advertisement.

It's an unpleasant experience for users because it make them think that it's their side that's broken rather than the support being incomplete.

[andrewrk]

please close the issue if you think it's fixed.

The progress on the libunwind front is indeed great news, however the stated problem is inability to compile hello world C code for powerpc-linux-gnu, which is still not solved.

I don't agree with making the support table more complicated, I think it's fine as is.

[nektro]

the tier system is very explicit. the full descriptions can be found here https://ziglang.org/download/0.8.0/release-notes.html#Tier-System

[andrewrk]

After #10339 is merged, Hello World is working for powerpc-linux-gnueabihf:

[nix-shell:~/Downloads/zig/build]$ ./zig build-exe hello.c -lc -target powerpc-linux-gnueabihf

[nix-shell:~/Downloads/zig/build]$ file hello
hello: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), dynamically linked, interpreter /lib/ld.so.1, for GNU/Linux 2.0.0, with debug_info, not stripped

[nix-shell:~/Downloads/zig/build]$ qemu-ppc -L ~/Downloads/glibc/multi-2.34/install/glibcs/powerpc-linux-gnu ./hello
hello!

Behavior tests are compiling but failing at runtime:

$ ./zig test ../test/behavior.zig -I ../test -target powerpc-linux-gnueabihf -lc
warning: the host system (x86_64-linux.5.10.81...5.10.81-gnu.2.33) does not appear to be capable of executing binaries from the target (powerpc-linux.3.16...5.10.81-gnueabihf.2.19). Consider using '--test-cmd qemu-ppc --test-cmd-bin' to run the tests
error: the following command failed with 'InvalidExe':
../test/zig-cache/o/a5a3cd97c00acaa78489380c826aff47/test /home/andy/Downloads/zig/build/zig

$ qemu-ppc -L ~/Downloads/glibc/multi-2.34/install/glibcs/powerpc-linux-gnu ../test/zig-cache/o/a5a3cd97c00acaa78489380c826aff47/test /home/andy/Downloads/zig/build/zig
Test [255/1078] behavior.atomics.test "128-bit cmpxchg"... SKIP
Test [505/1078] behavior.async_fn.test "@frameSize"... FAIL (TestUnexpectedResult)
/home/andy/Downloads/zig/test/behavior/error.zig:27:5: 0x100f599f in behavior.error.errBinaryOperatorG (test)
    return if (x) error.ItBroke else @as(isize, 10);
    ^
/home/andy/Downloads/zig/test/behavior/underscore.zig:18:5: 0x100f86a7 in behavior.underscore.optionalReturnError (test)
    return error.optionalReturnError;
    ^
/home/andy/Downloads/zig/test/behavior/while.zig:61:5: 0x100f8c57 in behavior.while.getNumberOrErr (test)
    return if (numbers_left == 0) error.OutOfNumbers else x: {
    ^
/home/andy/Downloads/zig/test/behavior/while.zig:205:5: 0x100f8df7 in behavior.while.returnError (test)
    return error.YouWantedAnError;
    ^
/home/andy/Downloads/zig/test/behavior/atomics.zig:95:42: 0x100f97ef in behavior.atomics.test_u128_cmpxchg (test)
        if (builtin.cpu.arch != .x86_64) return error.SkipZigTest;
                                         ^
/home/andy/Downloads/zig/test/behavior/atomics.zig:86:5: 0x10072d0f in behavior.atomics.test "128-bit cmpxchg" (test)
    try test_u128_cmpxchg();
    ^
/home/andy/Downloads/zig/lib/std/testing.zig:303:14: 0x100a4c13 in std.testing.expect (test)
    if (!ok) return error.TestUnexpectedResult;
             ^
/home/andy/Downloads/zig/test/behavior/async_fn.zig:123:17: 0x10109c8f in behavior.async_fn.S.doTheTest (test)
                try expect(size == @sizeOf(@Frame(other)));
                ^
/home/andy/Downloads/zig/test/behavior/async_fn.zig:142:5: 0x1007fe67 in behavior.async_fn.test "@frameSize" (test)
    try S.doTheTest();
    ^
Test [510/1078] behavior.async_fn.test "async fn pointer in a struct field"... thread 655057 panic: frame too small
/home/andy/Downloads/zig/test/behavior/async_fn.zig:297:15: 0x10080743 in behavior.async_fn.test "async fn pointer in a struct field" (test)
    const f = @asyncCall(&bytes, {}, foo.bar, .{&data});
              ^
/home/andy/Downloads/zig/lib/std/special/test_runner.zig:77:28: 0x100a6413 in std.special.main (test)
        } else test_fn.func();
                           ^
/home/andy/Downloads/zig/lib/std/start.zig:543:22: 0x100d45a3 in std.start.callMain (test)
            root.main();
                     ^
/home/andy/Downloads/zig/lib/std/start.zig:495:12: 0x100a84ef in std.start.callMainWithArgs (test)
    return @call(.{ .modifier = .always_inline }, callMain, .{});
           ^
/home/andy/Downloads/zig/lib/std/start.zig:460:12: 0x100a828b in std.start.main (test)
    return @call(.{ .modifier = .always_inline }, callMainWithArgs, .{ @intCast(usize, c_argc), c_argv, envp });
           ^
???:?:?: 0xfcfcb27 in ??? (???)
???:?:?: 0xfcfcc9f in ??? (???)
???:?:?: 0x0 in ??? (???)
Aborted (core dumped)