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 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
