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

[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.

[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.