r230255 - Only lower __builtin_setjmp / __builtin_longjmp to

[Hal Finkel]

----- Original Message -----
> From: "Joerg Sonnenberger" <joerg at britannica.bec.de>
> To: "John McCall" <rjmccall at gmail.com>
> Cc: hans at hanshq.net, "cfe-commits" <cfe-commits at cs.uiuc.edu>
> Sent: Tuesday, March 3, 2015 1:07:20 AM
> Subject: Re: r230255 - Only lower __builtin_setjmp / __builtin_longjmp to
> 
> 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.

Generically, these builtins are used in lightweight task-switching runtimes (that's why I implemented them in the PowerPC backend; it had nothing to do with EH) -- they're an order of magnitude faster than the function calls.

Also, as far as the PowerPC implementation is concerned, gcc compatibility is a non-goal. These are compiler builtins, and I don't consider them to be part of the ABI.

FWIW, I think that defaulting to the library implementation is reasonable, it does provide a valid (albeit slow) implementation.

 -Hal

> 
> > 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
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory