[libc-commits] [libc] [libc][cmake] Respect the configured optimization level for the Linux thread and TLS objects (PR #234382)

[Pavel Labath via libc-commits]

labath wrote:

Yeah, it sounds like we may need to revert this, at least for the time being. marking cpp::expected (and possibly others in the future) sounds like too much (though I think the other patch is still okay, as I don't like the idea of relying on optimization decisions for this ). @Prabhuk, would you be okay with that?

The unresolvable issue could be uhm... resolved coding the function in assembly like I did for thread creation, though I think it would be better to fix it by not unmapping one's own stack, as that would fix #235653 as well.

I'm not sure what to do about expected and memcpy. I wonder if we could do some namespacing tricks here -- e.g. compile the early startup code with a different value of LIBC_NAMESPACE, so that it does not collide with the symbols used by "normal" code. This sounds vaguely similar to Tue's idea for compiling the math functions multiple times. @lntue, could some of that machinery be applied here (basically we'd need to build some part of the code with -fno-stack-protector )?

https://github.com/llvm/llvm-project/pull/234382