Repository navigation
Windows: fork answers -1, so system* always spawns - #1
Merged
Merged
Conversation
The ntdll layer moved to lib/windows/ntdll.c and include/windows/ntdll.h, with include/windows/ntcall.h and lib/windows/x86-mes-m2/ntlow.c and ntcall.c beside it (a417554, f917901, 7e5bfdc), and the WOW64 files to lib/windows/ (dcd1876). 7baa813 split argv.M1 and defs.M1 out of crt1.M1 into lib/windows/x86-mes/ and moved pe-end.M1 there, and spawn.c (266ab1f) and filetime.c (00fbf64) were added. kaem.windows.run named five paths that no longer exist, so M2-Planet stopped at the first it could not open, and none of the seven files added since, among them spawn.c, which core:spawn calls, and defs.M1, without which M1 cannot assemble crt1.M1. * kaem.windows.run: Compile include/windows/ntdll.h and ntcall.h, lib/windows/x86-mes-m2/ntlow.c, ntcall.c and filetime.c, and lib/windows/ntdll.c, wow64gate.c, wow64resolve.c and spawn.c. Assemble with lib/windows/x86-mes/defs.M1, argv.M1 and pe-end.M1.
lib/windows/fork.c cloned the process with RtlCloneUserProcess. Wine's ntdll has no such export, so under Wine fork answered -1 and system* took its spawn branch; on Windows, every M1 and hex2 call MesCC makes would take the clone instead. On x64 the clone's child runs only after a heaven's gate into 64-bit ntdll and a write of four zero bytes into the child's ntdll, at an address computed from two RVAs measured on one Windows build. ARM64 emulates x86 with xtajit.dll and has no wow64cpu.dll, so there fork took the plain clone, which its own comment says was reasoned through rather than measured. The Windows lists now name lib/stub/fork.c, as they do for the other calls this port has no answer for. That stub answered 0, which tells a caller it is the child. It answers -1 with ENOSYS now, and gives no __mes_debug notice, since kaem.windows.run's M2-Planet list has no __mes_debug; lib/stub/__raise.c is the same plain form. This also changes the stub for the GNU/Hurd list, the only other one that names it, which has no spawn for core:spawn either. * lib/stub/fork.c (fork): Set errno to ENOSYS and return -1, with no __mes_debug notice. * build-aux/configure-lib.sh (libc_SOURCES) [windows]: Name lib/stub/fork.c instead of lib/windows/fork.c, wow64gate.c and wow64resolve.c. * kaem.windows.run: Likewise. * lib/windows/fork.c, lib/windows/wow64gate.c, lib/windows/wow64resolve.c, scaffold/boot/fork-test.scm: Remove. * include/windows/ntdll.h (__walloc16, __qadd64): Remove declarations. * mes/module/mes/posix.mes (system*): Update comment. * src/posix.c (spawn_): Likewise. * lib/windows/spawn.c (spawn): Likewise. * lib/windows/ntdll.c (__ntdll_find_module, __ntdll_resolve_export): Likewise. * scaffold/ntdll-resolve-test.c (main): Likewise.
The head comments of lib/windows/ntdll.c and include/windows/ntdll.h told how the layer came to be, named lib/windows/ntdll.h for include/windows/ntdll.h, placed __ntdll in ntdll.c where it is in ntlow.c, and said nothing compiled from C calls __ntdll, which scaffold/ntdll-resolve-test.c does. * lib/windows/ntdll.c: Rewrite the head comment. * include/windows/ntdll.h: Likewise for the slot table's. * scaffold/ntdll-resolve-test.c (main): Say why NT_CLONE is not checked.
include/mes/lib.h declares __mesabi_uldiv on unsigned long, as its name says, while lib/mes/ntoab.c defined it, and the values ntoab hands it, on size_t. The two are one type only where size_t is unsigned long, which Mes's own headers make it for every compiler but M2-Planet. Where it is unsigned int, as an i386 compiler's own stddef.h has it, ntoab.c fails with conflicting types for __mesabi_uldiv. nixpkgs makes this change with replace in pkgs/os-specific/linux/minimal-bootstrap/mes/default.nix, from nixpkgs commit 839e2de5d85649c01cd99f6da861747385e4feab, unchanged at 510ce503d5055ea25a461f95b793ee992a650d44. GNU Mes does not have it as of master 746a8209, after 0.28. * lib/mes/ntoab.c (__mesabi_uldiv): Use unsigned long. (ntoab): Likewise for i, u and b.
include/sys/ioctl.h declares ioctl3's command unsigned long for every compiler but M2-Planet, which sees unsigned, and lib/stub/ioctl3.c defines it so. include/mes/lib.h declared it, and lib/linux/ioctl3.c and lib/windows/ioctl3.c defined it, size_t. Where size_t is unsigned int, a file that includes both headers, as lib/posix/isatty.c does, fails with conflicting types for ioctl3. nixpkgs makes this change to include/mes/lib.h and lib/linux/ioctl3.c with replace in pkgs/os-specific/linux/minimal-bootstrap/mes/default.nix, from nixpkgs commit 839e2de5d85649c01cd99f6da861747385e4feab, unchanged at 510ce503d5055ea25a461f95b793ee992a650d44. lib/windows/ioctl3.c is this port's and gets the same change. GNU Mes does not have it as of master 746a8209, after 0.28. * include/mes/lib.h (ioctl3): Declare command unsigned long. * lib/linux/ioctl3.c (ioctl3): Define it so. * lib/windows/ioctl3.c (ioctl3): Likewise.
Without an l, an integer conversion's argument is an int or an unsigned int, and vfprintf read every one as a long. Where long is wider than int that reads bytes the argument does not have: built against a host C library on 64-bit Arm, %u of -1 printed 18446744073709551615 and %x of 0xdeadbeef printed ffffffffdeadbeef. Where int and long are one width, as on i686, the output is the same as before. ntoab is still asked for a signed result for %o, so there %o of a value above INT_MAX still prints with a minus sign. nixpkgs makes this change with replace in pkgs/os-specific/linux/minimal-bootstrap/mes/default.nix, from nixpkgs commit 839e2de5d85649c01cd99f6da861747385e4feab, unchanged at 510ce503d5055ea25a461f95b793ee992a650d44. This differs from it in three ways. The l is noted per conversion: nixpkgs' flag outlives a conversion that is not an integer, so after %lc its next %u reads a long. A second l still warns, where nixpkgs' replace of every match makes it a silent skip. And %e, %f and %g keep va_arg8: nixpkgs replaces it with va_arg, which include/stdarg.h, but for RISC-V and a system C library, defines as reading a long, converting its value to double and stepping ap by the size of a pointer. GNU Mes does not have the change as of master 746a8209, after 0.28. * lib/stdio/vfprintf.c (vfprintf): Read an integer conversion's argument as a long only after an l.
…int. The same fix vfprintf has: without an l, vsnprintf read an integer conversion's int or unsigned int argument as a long, which where long is wider than int reads bytes the argument does not have. Built against a host C library on 64-bit Arm, %u of -1 printed 18446744073709551615. On i686 the output is the same as before. nixpkgs makes this change with replace in pkgs/os-specific/linux/minimal-bootstrap/mes/default.nix, from nixpkgs commit 839e2de5d85649c01cd99f6da861747385e4feab, unchanged at 510ce503d5055ea25a461f95b793ee992a650d44. As for vfprintf, the l is noted per conversion, a third l still warns, and va_arg8 stays. GNU Mes does not have the change as of master 746a8209, after 0.28. * lib/stdio/vsnprintf.c (vsnprintf): Read an integer conversion's argument as a long only after an l.
The fork has no CI, so no run checks the Windows port on Windows. On windows-latest (x64, through WOW64) and windows-11-arm (through the x86 emulator), this builds stage0-pe32's chain at the commit nova-nix pins, mescc-tools-extra's mkdir with it, and mes-m2 with kaem.windows.run on a PATH of those tools alone. scaffold/spawn.scm then has mes-m2 check that primitive-fork answers -1 and start itself through system*, and fails unless the child's exit status comes back. The job also checks that the child's output reached the parent's. * .github/workflows/windows.yml: New file. * scaffold/spawn.scm: New file.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On Windows,
forkcloned the process withRtlCloneUserProcess(lib/windows/fork.c): on x64 a heaven's gate into 64-bit ntdll and a write into the child's ntdll at an address from two hardcoded RVAs, on ARM64 (nowow64cpu.dll) a plain clone nothing had measured. Wine has noRtlCloneUserProcess, sosystem*'s spawn branch ran only under Wine.forkanswers -1 withENOSYSfromlib/stub/fork.c, which answered 0, the child's answer. This also changes the GNU/Hurd list.fork.c,wow64gate.c,wow64resolve.candscaffold/boot/fork-test.scmare removed.kaem.windows.runnames the files the tree has: five of its paths were gone, and seven files it needs,spawn.camong them, were missing.ntoab,ioctl3,vfprintf,vsnprintf. The printf fix keepsva_arg8and noteslper conversion; the commits say why.strpbrkis already fixed. GNU Mes has none of the four as of 746a8209.kaem.windows.run, then runsscaffold/spawn.scm, onwindows-latestandwindows-11-arm.Not covered: MesCC's own M1 and hex2 calls and the MesCC-built C library (nova-nix issue 358).
system*still splitsPATHon:and looks for a bare name without.exe, so a name with no/is not found on Windows.Refs nova-nix issue 357.