std: add arch bits for m68k-linux

[sweiglbosker]

This pr provides initial support for m68k-linux within std.

Following #19510 (comment), i can build object files, but there is still no support for m68k within lld. Therefore, I can't link programs to test with qemu.

#23089
#22189

[alexrp]

Therefore, I can't link programs to test with qemu.

You can try adding a special case for m68k here:

zig/src/link/Elf.zig

Line 1666 in db7db48

if (output_mode == .Obj and (comp.config.lto != .none or target.cpu.arch.isBpf())) {

Then use GNU ld to link the resulting object file. It'll be super janky, but maybe it can get you somewhere. But if not, don't worry about it.

You can also try building a basic program or even the behavior tests with -fno-emit-bin just to see if they pass semantic analysis.

[sweiglbosker]

besides the MMAP2_UNIT issue, there is one more im getting:
std.fs.File.Stat.FromLinux() tries to coerce the u64 inode number in Statx to the target system.ino_t (u32 for m68k).
from what I can tell these types are accurate to what is in glibc/linux (statx is u64, stat is u32); it looks like fromLinux might be the issue here.

~/src/zigm68k [i]
λ ~/src/zig/build/stage3/bin/zig build-obj test.zig -target "m68k-linux" --zig-lib-dir "$(realpath ~/src/zig/lib)"
/home/stefan/src/zig/lib/std/fs/File.zig:436:25: error: expected type 'u32', found 'u64'
            .inode = stx.ino,
                     ~~~^~~~
/home/stefan/src/zig/lib/std/fs/File.zig:436:25: note: unsigned 32-bit int cannot represent all possible unsigned 64-bit values
/home/stefan/src/zig/lib/std/os/linux.zig:910:52: error: type 'u64' cannot represent integer value '-1'
            @truncate(@as(u64, @bitCast(offset)) / MMAP2_UNIT),
                                                   ^~~~~~~~~~
/home/stefan/src/zig/lib/std/os/linux/tls.zig:542:68: error: type 'u64' cannot represent integer value '-1'
            @as(usize, @truncate(@as(u64, @bitCast(offset)) / linux.MMAP2_UNIT)),
                                                              ~~~~~^~~~~~~~~~~
/home/stefan/src/zig/lib/std/os/linux/tls.zig:511:32: note: called from here
        const begin_addr = mmap(
                           ~~~~^
referenced by:
    posixCallMainAndExit: /home/stefan/src/zig/lib/std/start.zig:547:40
    _start: /home/stefan/src/zig/lib/std/start.zig:464:40
    3 reference(s) hidden; use '-freference-trace=5' to see all references

I imagine the fix would simply be to change the std.os.File.Stat.inode to be a u64.

[sweiglbosker]

fixed all the issues I could find; the behavior tests seem to be in a good spot now.

~/src/zig/build [i]
λ ./stage3/bin/zig test -fno-emit-bin ../test/behavior.zig -target m68k-linux --test-cmd qemu-m68k --test-cmd-bin --zig-lib-dir "$(realpath ~/src/zig/lib)"
/home/stefan/src/zig/lib/std/Thread.zig:1383:36: error: Unsupported linux arch: m68k
                else => |cpu_arch| @compileError("Unsupported linux arch: " ++ @tagName(cpu_arch)),
                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
referenced by:
    entryFn: /home/stefan/src/zig/lib/std/Thread.zig:1401:57
    spawn__anon_25348: /home/stefan/src/zig/lib/std/Thread.zig:1495:21
    9 reference(s) hidden; use '-freference-trace=11' to see all references
/home/stefan/src/zig/lib/std/builtin.zig:984:13: error: VaList not supported for this target yet
    else => @compileError("VaList not supported for this target yet"),
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[sweiglbosker]

Its building now, but with a segfault during compilation. Any idea how to debug this?

~/src/m68ktest [i]
λ ~/src/zig/build/stage3/bin/zig build-obj -fno-emit-bin -femit-asm="test.s" -target "m68k-linux" --zig-lib-dir "$(realpath ~/src/zig/lib)" -fno-unwind-tables -fomit-frame-pointer thing.zig 
thread 26381 panic: Segmentation fault at address 0x3
???:?:?: 0xd237ed2 in ??? (???)
???:?:?: 0xd23a2d6 in ??? (???)
???:?:?: 0x467dcddf in ??? (???)
Unwind information for `???:0x467dcddf` was not available, trace may be incomplete

zsh: IOT instruction  ~/src/zig/build/stage3/bin/zig build-obj -fno-emit-bin -femit-asm="test.s"

[sweiglbosker]

Oh yeah it looks like the change to Stat breaks a bunch of stuff so I need to fix that

[alexrp]

Its building now, but with a segfault during compilation. Any idea how to debug this?

Get a debug build of stage4 by doing e.g. ./build/stage3/bin/zig build -Dno-lib -Denable-llvm -Dllvm-has-m68k. Then use ./zig-out/bin/zig instead under GDB or LLDB.

When working on Zig, it's generally recommended to use stage3 only for building stage4. stage4 is then the compiler you use to run tests, etc. This way, you only have to rebuild stage3 -- which is a slow process as you've probably noticed -- once in a while when a backwards-incompatible change is made.

[sweiglbosker]

crash caused when llvm tries to emit this instruction:
jsr (%pc, %a0). will do some more investigating when I have time

[alexrp]

Well, the m68k target in LLVM is still marked experimental, so some bugs are to be expected. I don't think it's worth spending too much time on unless you have a particular interest in it.

[sweiglbosker]

Yeah if this doesn’t break anything else (which i haven't checked yet) it can probably be merged

[sweiglbosker]

zig/lib/std/start.zig

Line 360 in f296eec

\\ jsr (%%pc, %%a0)

welp, I found the offending line from earlier, maybe this addressing mode isn't supported by llvm atm

[alexrp]

welp, I found the offending line from earlier, maybe this addressing mode isn't supported by llvm atm

Works fine in GNU as: https://godbolt.org/z/6Eeva3oTb

[sweiglbosker]

welp, I found the offending line from earlier, maybe this addressing mode isn't supported by llvm atm

Works fine in GNU as: https://godbolt.org/z/6Eeva3oTb

yeah that is definitely valid, its listed as one of the nine (lol) addressing modes that jsr can use in the user manual. needs to be fixed in llvm

[sweiglbosker]

https://godbolt.org/z/9MPrc9361
it seems that jsr is totally broken in llvm's m68k assembler, not something to be worried about here

[alexrp]

The merge conflict needs to be resolved in order to run CI.

[sweiglbosker]

There was a formatting issue, should be good now

[alexrp]

I'm a bit preoccupied with 0.14.1 release stuff at the moment, but I'll do a more thorough review pass over this when I have time. It looks good from a quick glance, but if I do find any problems, I'll just fix them before merging. Thanks!

[alexrp]

Made some changes:

• Rebased on master.
• Added stack alignment in start.zig.
• Switched to the clone() implementation from musl (with some changes) as I find it easier to read.
• Fixed the definitions of some basic types (off_t, ino_t, dev_t, and blkcnt_t), which in turn fixes the layout of Stat.
  • We end up using stat64() rather than the old stat() syscall, which means we do in fact get 64-bit inodes! This renders d7c2417 unnecessary.
  • Unfortunately we still get 32-bit time_t and it doesn't look like there's been any effort to fix that.
• Fixed the definition of O (it differs slightly from other architectures).

I've left the TODO regarding msghdr alone as I plan to clean the definitions of those up at some point.

@sweiglbosker please take a look over the changes and see if they make sense to you.

[sweiglbosker]

looks good. LGTM!