This is the mail archive of the
mailing list for the GCC project.
Re: avoid unnecessary register saves for setjmp
- From: "Zack Weinberg" <zack at codesourcery dot com>
- To: Chris Lattner <sabre at nondot dot org>
- Cc: Andrew Haley <aph at redhat dot com>, <Richard dot Earnshaw at arm dot com>, Jim Wilson <wilson at specifixinc dot com>, <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 27 Nov 2003 02:15:29 -0800
- Subject: Re: avoid unnecessary register saves for setjmp
- References: <Pine.LNX.email@example.com>
Chris Lattner <firstname.lastname@example.org> writes:
> On Thu, 27 Nov 2003, Zack Weinberg wrote:
>> >From a language-design perspective it's desirable for x to have the
>> value 23 in both fragments. (Leaving out the volatile on x is
>> intentional.) Its being undefined in C is a source of hard-to-find
>> bugs. It happens because longjmp() can't know which registers need
>> restoring, whereas the EH unwinder does know and can get it
>> (abstractly) right. So by using the EH unwinder for longjmp we clean
>> up a nasty dark corner of the language.
> Also, ideally, longjmp should run cleanups in intervening stackframes,
> which the LLVM implementation does, just like for pthreads cancellation.
Right. (The IA64 psABI seems to anticipate that some people expect it
*not* to, by providing longjmp_unwind.)
>> To be fair, an argument against this change is that it would break
>> code that uses setjmp and longjmp to implement coroutine linkage.
>> (The set/get/make/swapcontext calls are better for this, but that
>> doesn't mean everyone uses them.)
> I don't believe that this is actually legal ANSI C. You can only return
> to a place that has been setjmp'd to, there is no way to 'construct' a
> jmpbuf. Likewise, you cannot setjmp, return from the setjmp'ing function,
> then longjmp back to the 'dead' jmpbuf.
No, no it isn't.