This is the mail archive of the
mailing list for the binutils project.
Re: Support setjmp in x86-64 psABI with AVX-512
- From: Rich Felker <dalias at aerifal dot cx>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, GCC Development <gcc at gcc dot gnu dot org>, Binutils <binutils at sourceware dot org>
- Date: Sat, 27 Jul 2013 16:09:22 -0400
- Subject: Re: Support setjmp in x86-64 psABI with AVX-512
- References: <CAMe9rOrvMxSLj3LcYBs71tVdw6C0vJFKD2HxvnoHc13UamftwA at mail dot gmail dot com> <ddab98c2-bb3b-4d02-b403-e7d5690cfe00 at email dot android dot com> <CAMe9rOpxErCVtE-PDZ3Yb9mL+4E+XQ-are9Df4YBbEioj+MmZA at mail dot gmail dot com> <b9c5d467-834a-4b57-b48c-ac4bb450c9e5 at email dot android dot com> <20130725030655 dot GL14138 at laptop dot redhat dot com> <20130725065538 dot GA18427 at domone dot kolej dot mff dot cuni dot cz> <20130725165053 dot GJ4284 at brightrain dot aerifal dot cx> <20130727154405 dot GA25725 at domone dot kolej dot mff dot cuni dot cz> <20130727161257 dot GY4284 at brightrain dot aerifal dot cx> <20130727182707 dot GA5625 at domone dot kolej dot mff dot cuni dot cz>
On Sat, Jul 27, 2013 at 08:27:07PM +0200, OndÅej BÃlka wrote:
> On Sat, Jul 27, 2013 at 12:12:57PM -0400, Rich Felker wrote:
> > On Sat, Jul 27, 2013 at 05:44:05PM +0200, OndÅej BÃlka wrote:
> > > On Thu, Jul 25, 2013 at 12:50:53PM -0400, Rich Felker wrote:
> > > > On Thu, Jul 25, 2013 at 08:55:38AM +0200, OndÅej BÃlka wrote:
> > > > You can't add call-saved registers without breaking the ABI, because
> > > > they need to be saved in the jmp_buf, which does not have space for
> > > > them.
> > > >
> > > Well you can. Use versioning, structure will not change and layout for
> > > old setjmp/longjmp is unchanged. For new setjmp we set jump address to
> > > jmp_buf address to distinguish it from first case. Then for each thread
> > > we keep a stack with extra space needed to save additional registers.
> > > When setjmp/longjmp is called we prune frames from exited functions.
> > This required unbounded storage which does not exist. From a practical
> > standpoint you would either have to reserve a huge amount of storage
> > (e.g. double the allocated thread stack size and use half of it as
> > reserved space for jmp_buf) or make the calling program crash when the
> Standard trick mmap and double.
> > small, reasonable amount of reserved space is exhausted. The latter is
> > highly unacceptable since the main purpose (IMO:) of jmp_buf is to
> > work around bad library code that can't handle resource exhaustion by
> > replacing its 'xmalloc' type functions with ones that longjmp to a
> > thread-local jmp_buf set by the caller (e.g. this is the only way to
> > use glib robustly).
> Well what I wrote is to work around pathologic cases.
> With versioning and changing size of structure I could do trick with
> distinguishing by pointing to itself and it would mostly work.
> It would break when function that uses setjmp obtains jmp_buf by
> parameter from other unit.
This is a fairly reasonable usage, e.g. when the jmp_buf is part of
some context structure passed around, and different call levels want
to replace it to 'handle exceptions'. Personally, I think the right
solution is to use a jmp_buf* in the context rather than a jmp_buf, so
different call levels can swap around which one it points to (and so
the ultimate caller can re-use the same jmp_buf in multiple contexts),
but I can't force everybody to do The Right Thing. If code is valid,
conforming C (and sometimes even when it's not) then it needs to be
supported by the implementation.
> To avoid it we need allocate some extra space. Most programs would have
> number of jmp_buf instances limited so not deallocating extra would not
> cause problem. To violate that limit you need to have variation to these:
Well the number of jmp_buf instances you could use in a reasonable
sense is limited by the stack size/number of call frames, which is why
I thought a "safe" amount of space would be equal to the size of the
stack. However as you've said, one could allocate many more...
> > By the way, I do have another horrible idea for how you could do it.
> Next idea would be hack gcc to mark all variables volatile in functions
> with setjmp.
That does not help. setjmp may not be backing up the caller's
variables, but rather register values belonging to
(the caller of)^N the caller
for arbitrarily large values of N.