Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

zig cc -c -fstack-protector stopped working #18009

Closed
markus-oberhumer opened this issue Nov 15, 2023 · 7 comments
Closed

zig cc -c -fstack-protector stopped working #18009

markus-oberhumer opened this issue Nov 15, 2023 · 7 comments
Labels
bug Observed behavior contradicts documented or intended behavior frontend Tokenization, parsing, AstGen, Sema, and Liveness. regression It worked in a previous version of Zig, but stopped working. zig cc Zig as a drop-in C compiler feature
Milestone
0.12.0

Comments

@markus-oberhumer
Copy link
Contributor

Zig Version

0.12.0-dev.1607+f8b38a174

Steps to Reproduce and Observed Behavior

At https://github.com/upx/upx-test-build-with-zig we are continuously testing building UPX for 104 different build targets, and it seems that recently -fstack-protector as used in zig cc -c -fstack-protector stopped working

Possible cause: commit 53f74d6 by @andrewrk

# create a C test file that uses some stack
echo 'void foo(void *); void bar(void) { char stack[256 * 1024]; foo(stack); }' > x.c

# works
./zig-linux-x86_64-0.12.0-dev.1504+81219586b/zig cc -target x86_64-linux-musl -fstack-protector -c x.c

# FAILS
./zig-linux-x86_64-0.12.0-dev.1607+f8b38a174/zig cc -target x86_64-linux-musl -fstack-protector -c x.c
error: unable to create compilation: StackProtectorUnsupportedByTarget

Expected Behavior

No error.
@markus-oberhumer markus-oberhumer added the bug Observed behavior contradicts documented or intended behavior label Nov 15, 2023
@matu3ba
Copy link
Contributor

matu3ba commented Nov 16, 2023 •
edited
Loading

This breaks also native/non-crosscompiled code relying on stack-protectors:

git clone https://github.com/rui314/mold.git && cd mold
mkdir -p build && cd build
cd "$HOME/dev/git/cpp/mold/build"
cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_COMPILER="zig;c++" ..
cmake --build . -j $(nproc)
[  2%] Building CXX object third-party/tbb/src/tbb/CMakeFiles/tbb.dir/allocator.cpp.o
error: unable to create compilation: StackProtectorUnsupportedByTarget
make[2]: *** [third-party/tbb/src/tbb/CMakeFiles/tbb.dir/build.make:76: third-party/tbb/src/tbb/CMakeFiles/tbb.dir/address_waiter.cpp.o] Fehler 1
make[2]: *** Es wird auf noch nicht beendete Prozesse gewartet …
error: unable to create compilation: StackProtectorUnsupportedByTarget
make[2]: *** [third-party/tbb/src/tbb/CMakeFiles/tbb.dir/build.make:90: third-party/tbb/src/tbb/CMakeFiles/tbb.dir/allocator.cpp.o] Fehler 1
[  2%] Building C object third-party/mimalloc/CMakeFiles/mimalloc-static.dir/src/bitmap.c.o
make[1]: *** [CMakeFiles/Makefile2:1193: third-party/tbb/src/tbb/CMakeFiles/tbb.dir/all] Fehler 2
make[1]: *** Es wird auf noch nicht beendete Prozesse gewartet …

@SuperAuguste SuperAuguste mentioned this issue Nov 28, 2023
Closed
@Vexu Vexu added frontend Tokenization, parsing, AstGen, Sema, and Liveness. zig cc Zig as a drop-in C compiler feature labels Nov 28, 2023
@Vexu Vexu added this to the 0.12.0 milestone Nov 28, 2023
@Vexu Vexu added the regression It worked in a previous version of Zig, but stopped working. label Nov 28, 2023
@Vexu
Copy link
Member

Vexu commented Nov 28, 2023

Regressed by 53f74d6, use_llvm is false when there is no Zig module so zigBackend selects stage2_x86_64 which doesn't support stack protectors.

@odyslam odyslam mentioned this issue Dec 2, 2023
Open
@odyslam
Copy link

odyslam commented Dec 2, 2023

Is there is a temporary solution to this? Install a version of zig prior to 53f74d6?

@Vexu
Copy link
Member

Vexu commented Dec 2, 2023 •
edited
Loading

Adding -fllvm should work. Nevermind, it's not available for zig cc.

@xxxbxxx xxxbxxx mentioned this issue Dec 7, 2023
Closed
@xxxbxxx
Copy link
Contributor

xxxbxxx commented Dec 7, 2023

depending on the intended meaning of use_llvm, the fix may be along the lines of:
#18114 (comment)

@markus-oberhumer
Copy link
Contributor Author

Any news on this issue? It looks like zig cc could need some love...

@Vexu
Copy link
Member

Vexu commented Dec 10, 2023

depending on the intended meaning of use_llvm, the fix may be along the lines of: #18114 (comment)

This patch looks good except the frontend check needs to go before the main_mod == null check.

@xxxbxxx xxxbxxx mentioned this issue Dec 11, 2023
Closed
andrewrk added a commit that referenced this issue Dec 14, 2023
@andrewrk
frontend: fix stack protector option logic
5fdc8bc 
Commit 97e2389 regressed this behavior
because it made target_util.supportsStackProtector *correctly*
notice which zig backend is being used to generate code, while the
logic calling that function *incorrectly assumed* that .zig code is being
compiled, when in reality it might be only C code being compiled.

This commit adjusts the option resolution logic for stack protector so
that it takes into account the zig backend only if there is a zig
compilation unit. A separate piece of logic checks whether clang
supports stack protector for a given target.

closes #18009
closes #18114
closes #18254
andrewrk added a commit that referenced this issue Dec 19, 2023
@andrewrk
frontend: fix stack protector option logic
69c8e8e 
Commit 97e2389 regressed this behavior
because it made target_util.supportsStackProtector *correctly*
notice which zig backend is being used to generate code, while the
logic calling that function *incorrectly assumed* that .zig code is being
compiled, when in reality it might be only C code being compiled.

This commit adjusts the option resolution logic for stack protector so
that it takes into account the zig backend only if there is a zig
compilation unit. A separate piece of logic checks whether clang
supports stack protector for a given target.

closes #18009
closes #18114
closes #18254
andrewrk added a commit that referenced this issue Dec 25, 2023
@andrewrk
frontend: fix stack protector option logic
9a75606 
Commit 97e2389 regressed this behavior
because it made target_util.supportsStackProtector *correctly*
notice which zig backend is being used to generate code, while the
logic calling that function *incorrectly assumed* that .zig code is being
compiled, when in reality it might be only C code being compiled.

This commit adjusts the option resolution logic for stack protector so
that it takes into account the zig backend only if there is a zig
compilation unit. A separate piece of logic checks whether clang
supports stack protector for a given target.

closes #18009
closes #18114
closes #18254
andrewrk added a commit that referenced this issue Dec 27, 2023
@andrewrk
frontend: fix stack protector option logic
73eba36 
Commit 97e2389 regressed this behavior
because it made target_util.supportsStackProtector *correctly*
notice which zig backend is being used to generate code, while the
logic calling that function *incorrectly assumed* that .zig code is being
compiled, when in reality it might be only C code being compiled.

This commit adjusts the option resolution logic for stack protector so
that it takes into account the zig backend only if there is a zig
compilation unit. A separate piece of logic checks whether clang
supports stack protector for a given target.

closes #18009
closes #18114
closes #18254
andrewrk added a commit that referenced this issue Dec 28, 2023
@andrewrk
frontend: fix stack protector option logic
f8e8acd 
Commit 97e2389 regressed this behavior
because it made target_util.supportsStackProtector *correctly*
notice which zig backend is being used to generate code, while the
logic calling that function *incorrectly assumed* that .zig code is being
compiled, when in reality it might be only C code being compiled.

This commit adjusts the option resolution logic for stack protector so
that it takes into account the zig backend only if there is a zig
compilation unit. A separate piece of logic checks whether clang
supports stack protector for a given target.

closes #18009
closes #18114
closes #18254
andrewrk added a commit that referenced this issue Dec 29, 2023
@andrewrk
frontend: fix stack protector option logic
c9a07e9 
Commit 97e2389 regressed this behavior
because it made target_util.supportsStackProtector *correctly*
notice which zig backend is being used to generate code, while the
logic calling that function *incorrectly assumed* that .zig code is being
compiled, when in reality it might be only C code being compiled.

This commit adjusts the option resolution logic for stack protector so
that it takes into account the zig backend only if there is a zig
compilation unit. A separate piece of logic checks whether clang
supports stack protector for a given target.

closes #18009
closes #18114
closes #18254
andrewrk added a commit that referenced this issue Dec 29, 2023
@andrewrk
frontend: fix stack protector option logic
58fd666 
Commit 97e2389 regressed this behavior
because it made target_util.supportsStackProtector *correctly*
notice which zig backend is being used to generate code, while the
logic calling that function *incorrectly assumed* that .zig code is being
compiled, when in reality it might be only C code being compiled.

This commit adjusts the option resolution logic for stack protector so
that it takes into account the zig backend only if there is a zig
compilation unit. A separate piece of logic checks whether clang
supports stack protector for a given target.

closes #18009
closes #18114
closes #18254
andrewrk added a commit that referenced this issue Jan 1, 2024
@andrewrk
frontend: fix stack protector option logic
1317b02 
Commit 97e2389 regressed this behavior
because it made target_util.supportsStackProtector *correctly*
notice which zig backend is being used to generate code, while the
logic calling that function *incorrectly assumed* that .zig code is being
compiled, when in reality it might be only C code being compiled.

This commit adjusts the option resolution logic for stack protector so
that it takes into account the zig backend only if there is a zig
compilation unit. A separate piece of logic checks whether clang
supports stack protector for a given target.

closes #18009
closes #18114
closes #18254
andrewrk added a commit that referenced this issue Jan 2, 2024
@andrewrk
frontend: fix stack protector option logic
6664436 
Commit 97e2389 regressed this behavior
because it made target_util.supportsStackProtector *correctly*
notice which zig backend is being used to generate code, while the
logic calling that function *incorrectly assumed* that .zig code is being
compiled, when in reality it might be only C code being compiled.

This commit adjusts the option resolution logic for stack protector so
that it takes into account the zig backend only if there is a zig
compilation unit. A separate piece of logic checks whether clang
supports stack protector for a given target.

closes #18009
closes #18114
closes #18254
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Observed behavior contradicts documented or intended behavior frontend Tokenization, parsing, AstGen, Sema, and Liveness. regression It worked in a previous version of Zig, but stopped working. zig cc Zig as a drop-in C compiler feature
Projects
None yet
Milestone
0.12.0
5 participants
@markus-oberhumer @xxxbxxx @matu3ba @odyslam @Vexu