[libc-commits] [libc] [libc][setjmp] fix setjmp test (PR #87837)

[Nick Desaulniers via libc-commits]

nickdesaulniers wrote:

> Document _why_ this small number of functions must be implemented fully in asm (that it's not about performance!), and that solves that problem.

I agree and I think having the project's stance on out of line asm written out and agreed to in advance would make these discussions easier and blameless in the future.  This should be link-able from https://libc.llvm.org/dev/code_style.html.

> > I've implemented setjmp here using a naked fn attr just to get a feel for it
> 
> That is a definite improvement. Using a naked function could be theoretically correct. However, this correctness applies ONLY if your code has a single asm statement. That significantly limits the usefulness of being in a C file.

Perhaps having the compiler generate debug info is a small consolation, but I agree the points in favor of maintaining these implementations are dwindling.

> 
> Compared to a standalone-asm file, a naked function has other downsides:
> 
> 1. There is a risk of a developer inadvertently putting non-asm code into the function, thus breaking the correctness (e.g. the `__builtin_return_address` call in the draft PR, or a theoretical call to a proposed `__builtin_stack_address`, or something else)
> 2. Compilers often fail to implement the attribute correctly, because it's such a rarely-used feature. GCC only supports it on a subset of platforms.

To me, 2 is the larger issue. We'll hit that when we revisit `setjmp`/`longjmp` for aarch64.  While we could drop support when using GCC as the host compiler for building those two functions for that one target, I'd rather not.

> The primary advantage I see of using inline-asm is the ability to use offsetof to get the offsets of jmp_buf members. If you instead write the function in a pure asm file, you'll need to get the applicable type-offsets into asm-usable `#define` statements. But, IMO that's not a huge problem (for these specific functions), because they are so extremely platform-specific already. It's not a big lift to write such offset defines manually, and then assert correspondence (that the `#define` values match the actual struct offsets) via static_assert on the C side.

I'll give it a shot in a new PR tomorrow.  That should give us a few options where we can better quantify the tradeoffs.

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