[pthread] Honor guard size in pthread_create

[sbc100]

Honor requested/default guard size in pthread_create by reserving guard_size bytes between thread control data/TSD/TLS and the usable stack.

Although we cannot set memory protection on this region like a native platform this can still be useful for catching and reporting overflows that are smaller than the guard region itself. Without this change -sSTACK_OVERFLOW_CHECK=1 is mostly useless for pthreads because any kind of overflow is likely to corrupt the stack before being reported.

Add test cases covering guard size queries via pthread_getattr_np and stack overflow detection within guard region.

Fixes: #27266

[sbc100]

ping @kripken, should be a quick one

[kripken]

😆 Not sure how this can be quick, I need to page back in all the stuff about how memory is managed here. Do we have that documented somewhere?

[sbc100]

😆 Not sure how this can be quick, I need to page back in all the stuff about how memory is managed here. Do we have that documented somewhere?

The public documenation for this is https://man7.org/linux/man-pages/man3/pthread_attr_setguardsize.3.html.

There are not really docs on how its implemented internally. The basic idea is fairly simple though: Each pthread has a guard region at the end of its stack (to detect and catch overflows). The size of the region is even controllable on a per-thread bases. Prior to this change we simply ignored this. Now we honor it. Its 8k by default:

emscripten/system/lib/libc/musl/src/internal/pthread_impl.h

Lines 277 to 283 in 4237a12

	#ifdef __EMSCRIPTEN__
	// Keep in sync with DEFAULT_PTHREAD_STACK_SIZE in settings.js
	#define DEFAULT_STACK_SIZE (64*1024)
	#else
	#define DEFAULT_STACK_SIZE 131072
	#endif
	#define DEFAULT_GUARD_SIZE 8192

This means per-thread overhead now defaults to 64k+8k rather than just 64k, but all of that is contollable at pthread-creation, these are just the default.

Since we don't have memory protection you could argue that maybe we only want to enable this in debug builds (where we have the basic stack checking enabled). But I'm not sure its worth the difference.

[sbc100]

Perhaps @stevenwdv can help review too?

[sbc100]

@kripken are you ok with @kleisauke's review here, or would you like to also approve?

[kripken]

Feel free to land, @kleisauke knows this code much better than me!

[stevenwdv]

Perhaps @stevenwdv can help review too?

Sorry for not responding, I was working on other stuff. In any case, I don't think my review would be of much use, since I don't know all the Pthread inners... I'm glad this is implemented now, though!