Skip to content

libco: select the fiber backend on Windows - #12

Open
hjiawei wants to merge 1 commit into
edsiper:masterfrom
hjiawei:mingw-fiber-backend
Open

libco: select the fiber backend on Windows#12
hjiawei wants to merge 1 commit into
edsiper:masterfrom
hjiawei:mingw-fiber-backend

Conversation

@hjiawei

@hjiawei hjiawei commented Jul 7, 2026

Copy link
Copy Markdown

On x86_64 the GNU/Clang branch of libco.c tests __amd64__ before _WIN32, so it includes amd64.c. That backend's co_swap executes a machine-code blob held in a read-only array, which faults under Data Execution Prevention on the first coroutine switch on Windows — exactly the failure the MSVC branch already sidesteps by disabling amd64.c "due to SIGSEGV bug" and falling back to fibers.

This moves the _WIN32 check ahead of the architecture checks so any Windows target (MSVC or MinGW-w64/GCC) uses the fiber.c backend (CreateFiber/SwitchToFiber). Non-Windows targets are unaffected; the later _WIN32 #elif (previously unreachable on x86_64) is removed.

Surfaced while cross-compiling a downstream consumer (fluent-bit) for Windows with the MinGW-w64 toolchain, where GCC defines __amd64__ and the old order silently selected the faulting backend.

On x86_64 the GNU/Clang branch tests __amd64__ before _WIN32 and pulls in
amd64.c. Its co_swap executes a machine-code blob stored in a read-only
array, which faults under Data Execution Prevention on the first coroutine
switch on Windows -- the same failure the MSVC branch already avoids by
disabling amd64.c "due to SIGSEGV bug". Check _WIN32 first so Windows
targets use the fiber backend (CreateFiber/SwitchToFiber) that MSVC uses,
regardless of the compiler (MSVC or MinGW-w64/GCC).

Signed-off-by: Jiawei Huang <jiawei@tigera.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant