Make errno a macro like on other platforms

[RReverser]

Currently wasi-libc makes errno a globally visible thread-local variable:

wasi-libc/libc-bottom-half/cloudlibc/src/libc/errno/errno.c

Line 87 in 38f4894

thread_local int errno = 0;

This differs from most other platforms - including underlying musl libc

wasi-libc/libc-top-half/musl/include/errno.h

Lines 10 to 21 in 38f4894

	#ifdef __wasilibc_unmodified_upstream /* Use alternate WASI libc headers */
	#include <bits/errno.h>
	#ifdef __GNUC__
	__attribute__((const))
	#endif
	int *__errno_location(void);
	#define errno (*__errno_location())
	#else
	#include <__errno.h>
	#include <__errno_values.h>
	#endif

- that define errno as just a macro that calls an internal function.

Would it be possible to change this to align the behaviour? I know it's somewhat niche usecase, but it seems to be the only big difference that prevents linking pre-existing object files produced by clang -target wasm32-wasi with Emscripten executables (emscripten-core/emscripten#19236) as object files depend on errno and it's not declared anywhere except wasi-libc.

[sbc100]

As long as there is no overhead, I don't see why we wouldn't just follow upstream musl on this. However, I think you would need to show that doing so didn't adding any overhead.

[sunfishcode]

ABI compatibility between wasi-libc and Emscripten would be error-prone at best, because the libc's have numerous differences which would lead to silent breakage. Also, while ABI compatibility has its advantages, it also has major advantages disadvantages, and with our current development resources, we can't remotely afford the kinds of costs it would entail to maintain any expectation of ABI compatibility.

[RReverser]

because the libc's have numerous differences which would lead to silent breakage

I know there are some historical differences between filesystem constants, but otherwise they both use musl and seem largely compatible, at least enough to work for my usecase.

I don't want to add undue maintenance burden and certainly don't expect any guarantees on ABI compatibility going forward, but I thought this particular difference is small enough to fix, and, if anything, might make the maintenance tiny bit simpler by reducing customized surface area vs just using what musl does.

[sunfishcode]

I'm not familiar with your use case, but even if it's small today, there's a risk it could grow in scope over time, or that other people might see what you're doing and want to do the same thing. For many projects, those are goals :-).

[RReverser]

That's a risk, yes, and, yes, secretly I'd hope someday Emscripten could actually be compatible with wasi-libc when in STANDALONE_WASM mode, but in this particular project I'm doing so much dangerous stuff already one more thing doesn't change much 😅

But basically I want to link a library built with Rust wasm32-wasi with Emscripten application built in STANDALONE_WASM mode. I could build Rust to wasm32-unknown-emscripten as well but historically that target in Rust is a bit problematic / undermaintained + it's crucial for me for that library to not depend on any of Emscripten's own custom imports which wasm32-unknown-emscripten can't guarantee even in STANDALONE_WASM mode (it all depends on features used) but wasm32-wasi can.

Either way, I thought this particular issue with thread-local might be worth looking at in isolation.