r230255 - Only lower __builtin_setjmp / __builtin_longjmp to

[Joerg Sonnenberger]

On Mon, Mar 02, 2015 at 06:02:32PM -0800, John McCall wrote:
> This patch is pretty scary.  __builtin_setjmp/longjmp are definitely not
> just libc functions with a __builtin_ prefix attached.  They do not
> interoperate with setjmp/longjmp and expect a significantly smaller buffer,
> so silently rewriting them to setjmp/longjmp is ABI-breaking.  This might
> fix Ruby, but only if Ruby is actually passing a full jmp_buf, and only if
> everything that does a __builtin_setjmp/__builtin_longjmp is recompiled in
> a way that does the rewrite.  I'm very concerned about this introducing ABI
> problems for a Clang-compiled Ruby with GCC-compiled extensions or
> vice-versa.  FWIW, Ruby seems to already have target-specific configuration
> logic for when to use them.

Ruby has no target-specific configuration. It builds a test program and
if that works, it picks them. Given that the current __builtin_setjmp /
__builtin_longjmp code is completely broken unless the backend has
explicit logic for that, the configure test in ruby will pass on all ARM
platforms except Darwin (where is might hit an assert or not).

No, they are not libc functions with a prefix as they are allowed to be
lowered to a different format. The builtin documentation is scarce at
best. It is a typically badly designed GCC builtin. There is a half
sentence in gccint.info about the buffer being 5 longs long, but even
the test suite is not consistent in that regard. It looks like a
completely messed up state.

Concerning ABI use: AFAICT, Ruby is the only thing outside an EH
implementation which actually tries to use them. It provides a correct
jmpbuf_t, so it gets a large enough buffer.

> Therefore, if we don't actually consistently support these builtins in the
> backend in a GCC-compatible way (quite plausible), I would be much more
> comfortable diagnosing that than silently rewriting them to setjmp/longjmp,
> unless there are platforms where GCC does actually rewrite them.  Have you
> done that investigation?

I have been discussing the approach and the lowering to a known-to-work
sj/lj seemed the least broken approach. I don't care enough about not
just bailing out in the frontend either. It is hard to tell what the
many different GCC configs are doing, I gave up.

Joerg