Compilation fails when --stack-first and -Oz are used together.

[netogallo]

Reproduction steps:

1. Use any c program. Take for example the following main.c

int main(int argc, char** argv) { return 0; }

2. Compile with /home/ernesto/code/emsdk/upstream/emscripten/emcc -Oz -Wl,--stack-first main.c
3. Compilation will fail with: "wasm-ld: error: --global-base cannot be less than stack size when --stack-first is used"
4. Now compile with /home/ernesto/code/emsdk/upstream/emscripten/emcc -Wl,--stack-first main.c compilation succeeds.

Workarounds:

1. Avoid "-Oz" when compiling with "--stack-first"
2. Edit "settings.js" and set "var GLOBAL_BASE = 1024;" to the same value as "var STACK_SIZE = 64*1024;"

Potential resolutions:

1. The "emcc.py" and "em++.py" programs can check if the "-Oz" flag is used together with "--stack-first". If so (Option 1) set the value of GLOBAL_BASE to the same value as STACK_SIZE. (Option 2) Exit with an error informing the user they are using an incompatible combination of flags.

Happy to issue a pull request with the fix above if any of those solutions would be satisfactory.

[sbc100]

The problem is that emscripten itself wants to control the --stack-first linker flag.

See

emscripten/tools/link.py

Lines 882 to 888 in 0e5b3a8

	if 'GLOBAL_BASE' not in user_settings and not settings.SHRINK_LEVEL and not settings.OPT_LEVEL:
	# When optimizing for size it helps to put static data first before
	# the stack (since this makes instructions for accessing this data
	# use a smaller LEB encoding).
	# However, for debugability is better to have the stack come first
	# (because stack overflows will trap rather than corrupting data).
	settings.STACK_FIRST = True

And:

emscripten/tools/building.py

Lines 245 to 246 in 0e5b3a8

	if settings.STACK_FIRST:
	cmd.append('--stack-first')

The idea is that we use stack-first in debug builds, but not in optimizing builds. Is there some reason you want the stack to be first, even in optimized builds?

[netogallo]

Thank you for letting me know. What you say is sensible. In case you are curious, the reason why I am attempting that is because I am trying to build GHC using the upstream emsdk (rather than using the wasm-sdk fork). The instructions use both flags: https://gitlab.haskell.org/ghc/ghc-wasm-meta#set-environment-variables

I don't know why they use "--stack-first" in all honesty, it might not be necessary as you say. This issue does not affect me as I can get around it. I was just reporting what I encountered. Feel free to close.

[sbc100]

Thanks for the report. We should certainly fix this (either by disallowing explicit -Wl,--stack-first or honoring it).

The reason that folks generally prefer --stack-first, and the reason emscripten uses it in debug builds, is that you get better stack overflow reporting. i.e. stack overflows will trap right away.