<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: arial,helvetica,sans-serif; font-size: 10pt; color: #000000'><br><hr id="zwchr"><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"John McCall" <rjmccall@gmail.com><br><b>To: </b>"Hal Finkel" <hfinkel@anl.gov><br><b>Cc: </b>"Joerg Sonnenberger" <joerg@britannica.bec.de>, "hans" <hans@hanshq.net>, "cfe-dev@cs.uiuc.edu Developers" <cfe-dev@cs.uiuc.edu><br><b>Sent: </b>Tuesday, March 3, 2015 6:45:56 PM<br><b>Subject: </b>Re: Are __builtin_setjmp / __builtin_longjmp part of the ABI?<br><br><div dir="ltr">On Tue, Mar 3, 2015 at 12:54 AM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><hr id="zwchr"><br>
> From: "John McCall" <<a href="mailto:rjmccall@gmail.com" target="_blank">rjmccall@gmail.com</a>><br>
> To: "Hal Finkel" <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>><br>
> Cc: "Joerg Sonnenberger" <<a href="mailto:joerg@britannica.bec.de" target="_blank">joerg@britannica.bec.de</a>>, "<<a href="mailto:hans@hanshq.net" target="_blank">hans@hanshq.net</a>>" <<a href="mailto:hans@hanshq.net" target="_blank">hans@hanshq.net</a>>, "cfe-commits"<br>
> <<a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.edu</a>><br>
> Sent: Tuesday, March 3, 2015 2:05:53 AM<br>
> Subject: Re: r230255 - Only lower __builtin_setjmp / __builtin_longjmp to<br>
><br>
> On Mar 2, 2015, at 11:22 PM, Hal Finkel <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>> wrote:<br>
> ><br>
> > ----- Original Message -----<br>
> >> From: "Joerg Sonnenberger" <<a href="mailto:joerg@britannica.bec.de" target="_blank">joerg@britannica.bec.de</a>><br>
> >> To: "John McCall" <<a href="mailto:rjmccall@gmail.com" target="_blank">rjmccall@gmail.com</a>><br>
> >> Cc: <a href="mailto:hans@hanshq.net" target="_blank">hans@hanshq.net</a>, "cfe-commits" <<a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.edu</a>><br>
> >> Sent: Tuesday, March 3, 2015 1:07:20 AM<br>
> >> Subject: Re: r230255 - Only lower __builtin_setjmp /<br>
> >> __builtin_longjmp to<br>
> >><br>
> >>> On Mon, Mar 02, 2015 at 06:02:32PM -0800, John McCall wrote:<br>
> >>> This patch is pretty scary. __builtin_setjmp/longjmp are<br>
> >>> definitely not<br>
> >>> just libc functions with a __builtin_ prefix attached. They do<br>
> >>> not<br>
> >>> interoperate with setjmp/longjmp and expect a significantly<br>
> >>> smaller<br>
> >>> buffer,<br>
> >>> so silently rewriting them to setjmp/longjmp is ABI-breaking.<br>
> >>> This<br>
> >>> might<br>
> >>> fix Ruby, but only if Ruby is actually passing a full jmp_buf,<br>
> >>> and<br>
> >>> only if<br>
> >>> everything that does a __builtin_setjmp/__builtin_longjmp is<br>
> >>> recompiled in<br>
> >>> a way that does the rewrite. I'm very concerned about this<br>
> >>> introducing ABI<br>
> >>> problems for a Clang-compiled Ruby with GCC-compiled extensions<br>
> >>> or<br>
> >>> vice-versa. FWIW, Ruby seems to already have target-specific<br>
> >>> configuration<br>
> >>> logic for when to use them.<br>
> >><br>
> >> Ruby has no target-specific configuration.<br>
><br>
> Literally the first google result for "Ruby __builtin_setjmp" is a<br>
> core commit turning it off for a target. Am I misunderstanding<br>
> something?<br>
><br>
> GCC implements this builtin with much more generality than we do,<br>
> probably because GCC predates widespread adoption of libUnwind and<br>
> we don't. Hal's comment about not trying to match GCC on PPC aside<br>
> (and I find that comment pretty troubling!),<br>
<br>
Hi John,<br>
<br>
Fair enough; let's move this question of whether __builtin_setjmp / __builtin_longjmp are part of the ABI to a separate thread.</blockquote><div><br></div><div>Thanks.</div><div> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">When implementing these for the PowerPC backend, I followed the same scheme as is used by the X86 backend, and so while this is likely compatible with GCC, I did not consider GCC compatibility a specific goal. Speed and correctness were all I cared about.<br>
<br>
My rational for not considering them to be part of the ABI is that:<br>
<br>
1. They don't appear in any system header<br></blockquote><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> 2. They don't appear in the system ABI documentation<br>
3. They're not universally supported by all compilers targeting the architecture</blockquote><div><br></div><div id="DWT3523">I think the crucial question is whether there's a reasonable assumption of interoperation with the compilers that do implement them.</div></div></div></div></blockquote><br>I don't think that there is, but in every use case I've come across, as you mention below with the Ruby case, the uses of these builtins is only an implementation detail internal to some library. It is very possible that some might disagree, and if so, I want to know that.<br><br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div id="DWT3524"> I think there's an expectation that these functions have a particular straightforward and efficient implementation; lowering them to less-efficient and incompatible functions that the user could simply have called themselves seems pointless.</div></div></div></div></blockquote><br>I agree. And as you pointed out below, we should try to be ABI compatible with ourselves, and we might wish to provide an optimized implementation at some point in the future.<br><br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div><br></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Generically, our implementation of __builtin_* (__builtin_<math func> for example) differs in observable ways from GCC's implementation.</blockquote><div><br></div><div id="DWT3525">That's true, but I think this is distinguishable.</div></div></div></div></blockquote>Fair enough.<br><br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">This does mean that passing a jmp_buf filled in by __builtin_setjmp across an interface boundary is a bad idea, but I never would have considered that to be a good idea anyway</blockquote><div><br></div><div id="DWT3526">It's necessary if you want to interoperate with e.g. an exception or continuation mechanism that's specified to use __builtin_setjmp or __builtin_longjmp. Most UNIX-like platforms these days use DWARF unwinding for things like C++ exceptions, but (1) not all of them and </div></div></div></div></blockquote><br>But when used for C++ exceptions, then they definitively are part of the ABI. The question is really are they part of the ABI otherwise?<br><br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>(2) language implementations besides C do exist, as the other thread attests. And it's actually pretty tricky to hide __builtin_setjmp behind an interface boundary, since the calling function can't exit without invalidating the buffer; you have to do it with callbacks.</div><div><br></div><div>It does seem that Ruby, at least, keeps this internal to its core implementation.</div><div> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">(because you already need to know it can only be used with __builtin_longjmp and not longjmp).<br></blockquote><div><br></div><div>That's a general thing with setjmp APIs. There are actually three different setjmp APIs in UNIX with buffer types that are typically interchangeable as arguments if you ask the C type system.</div><div><br></div><div id="DWT3527">In general, I think it's reasonable for users to have strong expectations about __builtin_setjmp / __builtin_longjmp. Targets should either implement this in a stable and ideally GCC-compatible way (and then consider the layout of a __builtin_jmp_buf to be ABI, and maybe we should put that in one of our compiler headers)</div></div></div></div></blockquote>Okay. I agree, at least, that we likely should not differ from GCC's implementation without some rationale.<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>, or the frontend shouldn't claim to support it. It's not like this is a core language feature; it's completely acceptable to just not provide the builtins on certain targets that don't support it.</div></div></div></div></blockquote>Agreed.<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div><br></div><div id="DWT3528">Even if we didn't care about GCC compatibility, having a default lowering to setjmp/longjmp makes it harder to adopt a better implementation in the future just within Clang, because it would basically be an ABI break between Clang v.X and Clang v.Y.</div></div></div></div></blockquote><br>Agreed.<br><br>Thanks again,<br>Hal<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div><br></div><div>John.</div></div>
</div></div>
</blockquote><br><br><br>-- <br><div><span name="x"></span>Hal Finkel<br>Assistant Computational Scientist<br>Leadership Computing Facility<br>Argonne National Laboratory<span name="x"></span><br></div></div></body></html>