Even though these registry mentions are supposed to be in a comment they
seem to still be interpreted by gcc.
Alternatively one could try to make zig not include comments in assembly
blocks when generating C code.
In function 'os_linux_x86_syscall6__6685',
inlined from 'os_linux_copy_file_range__4300' at zig2.c:396643:7,
inlined from 'link_MappedFile_copyFileRange__14079.isra' at zig2.c:289222:10:
zig2.c:396692:2: error: invalid 'asm': operand number missing after %-letter
396692 | __asm volatile(" push %[args56]\n push %%ebp\n mov 4(%%esp), %%ebp\n mov %%edi, 4(%%esp)\n // The saved %edi and %ebp are on the stack, and %ebp points to `args56`.\n // Prepare the last two args, syscall, then pop the saved %ebp and %edi.\n mov (%%ebp), %%edi\n mov 4(%%ebp), %%ebp\n int $0x80\n pop %%ebp\n pop %%edi": [ret]"=r"(t5): [number]"r"(t6), [arg1]"r"(t7), [arg2]"r"(t8), [arg3]"r"(t9), [arg4]"r"(t10), [args56]"rm"(t2): "memory");
| ^~~~~
zig2.c:396692:2: error: invalid 'asm': operand number missing after %-letter
zig2.c:396692:2: error: invalid 'asm': operand number missing after %-letter
zig2.c:396692:2: error: invalid 'asm': operand number missing after %-letter
zig2.c:396692:2: error: invalid 'asm': operand number missing after %-letter
This required a thorough audit of every syscall wrapper in std.os.linux, so
while I was here, I fixed some minor arch-specific bugs, improved some types,
simplified some casts, and deleted some dead code.
Note that lseek() in particular is still broken for n32 and x32 after this
commit; this wrapper will require some special-casing in the arch bits due to
its unusual return type width.
closes https://github.com/ziglang/zig/issues/22464
closes https://codeberg.org/ziglang/zig/issues/31597
Some initial work towards https://codeberg.org/ziglang/zig/issues/31414.
Conclusion from this: Only x86-freebsd, x86-haiku, and x86-illumos remain time32
and are currently unfixable. I don't think the upstreams for any of these
targets actually care about them anymore (probably why they weren't migrated to
time64), so this is not a particularly big concern.
I split UTIME constants out from timespec because they were causing unreasonable
code duplication by being there.
We can directly access this path string from the PEB (albeit with some
weirdness around addressing) and that ends up making the downstream code
simpler and more efficient. (Almost like the kernel32 API isn't very
good!)
The change in codegen/x86_64/CodeGen.zig was not strictly necessary (the
Sema change I did solves the error I was getting there), I just think
it's better style anyway.
The dependency on advapi32.dll actually silently brings along 3 other dlls at runtime (msvcrt.dll, sechost.dll, bcrypt.dll), even if no advapi32 APIs are called. So, this commit actually reduces the number of dlls loaded at runtime by 4 (but only when LLVM is not linked, since LLVM has its own dependency on advapi32.dll).
The data is not super conclusive, but the ntdll version of WindowsSdk appears to run slightly faster than the previous advapi32 version:
Benchmark 1: libc-ntdll.exe ..
Time (mean ± σ): 6.0 ms ± 0.6 ms [User: 3.9 ms, System: 7.1 ms]
Range (min … max): 4.8 ms … 7.9 ms 112 runs
Benchmark 2: libc-advapi32.exe ..
Time (mean ± σ): 7.2 ms ± 0.5 ms [User: 5.4 ms, System: 9.2 ms]
Range (min … max): 6.1 ms … 8.9 ms 103 runs
Summary
'libc-ntdll.exe ..' ran
1.21 ± 0.15 times faster than 'libc-advapi32.exe ..'
and this mostly seems to be due to changes in the implementation (the advapi32 APIs do a lot of NtQueryKey calls that the new implementation doesn't do) rather than due to the decrease in dll loading. LLVM-less zig binaries don't show the same reduction (the only difference here is the DLLs being loaded):
Benchmark 1: stage4-ntdll\bin\zig.exe version
Time (mean ± σ): 3.0 ms ± 0.6 ms [User: 5.3 ms, System: 4.8 ms]
Range (min … max): 1.3 ms … 4.2 ms 112 runs
Benchmark 2: stage4-advapi32\bin\zig.exe version
Time (mean ± σ): 3.5 ms ± 0.6 ms [User: 6.9 ms, System: 5.5 ms]
Range (min … max): 2.5 ms … 5.9 ms 111 runs
Summary
'stage4-ntdll\bin\zig.exe version' ran
1.16 ± 0.28 times faster than 'stage4-advapi32\bin\zig.exe version'
---
With the removal of the advapi32 dependency, the non-ntdll dependencies that remain in an LLVM-less Zig binary are ws2_32.dll (which brings along rpcrt4.dll at runtime), kernel32.dll (which brings along kernelbase.dll at runtime), and crypt32.dll (which brings along ucrtbase.dll at runtime).
Alex Rønne Petersen