llvm dev - Apr 2014 - [LLVMdev] Proposal: Loads/stores with deterministic trap/unwind behavior

On Tue, Apr 01, 2014 at 11:35:16AM -0500, Krzysztof Parzyszek
wrote:
> How do you plan to actually create the exception?
The runtime library can invoke the unwinder directly (i.e. using
_Unwind_RaiseException).
> You cannot simply  
> throw an exception (via "throw" statement) from a signal handler
because
> the unwinding won't happen properly.  To make it work you'll need a
> runtime support to indicate the origin of the exception (i.e. the  
> address of the offending load/store). Alternatively, you could insert  
> runtime checks at the loads/stores, but then it won't be
"zero-cost".
I'm pretty sure that it is possible to unwind through signal handlers. This
is, for example, how gccgo implements some run-time panics.

Thanks,
-- 
Peter

On 1 Apr 2014, at 19:38, Peter Collingbourne <peter at pcc.me.uk> wrote:
> I'm pretty sure that it is possible to unwind through signal handlers.
This
> is, for example, how gccgo implements some run-time panics.
It' highly OS dependent and not something to rely on for any
vaguely-portable code.  We do support it in FreeBSD, but the extra logic caused
a slowdown that users objected to when we introduced it and so I can well
imagine that other systems would prefer the faster approach - it has some quite
nasty interactions with the run-time linker.  From what I recall, at least one
of the other UNIX-like systems that we looked at did claim to support it, but
got the locking wrong so it worked fine 99% of the time and deadlocked the
remaining 1%...

David

On Tue, Apr 01, 2014 at 09:03:10PM +0100, David Chisnall
wrote:
> On 1 Apr 2014, at 19:38, Peter Collingbourne <peter at pcc.me.uk>
wrote:
> 
> > I'm pretty sure that it is possible to unwind through signal
handlers. This
> > is, for example, how gccgo implements some run-time panics.
> 
> It' highly OS dependent and not something to rely on for any
vaguely-portable code.  We do support it in FreeBSD, but the extra logic caused
a slowdown that users objected to when we introduced it and so I can well
imagine that other systems would prefer the faster approach - it has some quite
nasty interactions with the run-time linker.  From what I recall, at least one
of the other UNIX-like systems that we looked at did claim to support it, but
got the locking wrong so it worked fine 99% of the time and deadlocked the
remaining 1%...
Right, this feature would obviously require a certain level of OS support
and I'd expect a portable compiler to be able to pick a compatible way to
implement null checks.

Thanks,
-- 
Peter

On Tue, Apr 01, 2014 at 09:03:10PM +0100, David Chisnall
wrote:
> On 1 Apr 2014, at 19:38, Peter Collingbourne <peter at pcc.me.uk>
wrote:
> 
> > I'm pretty sure that it is possible to unwind through signal
handlers. This
> > is, for example, how gccgo implements some run-time panics.
> 
> It' highly OS dependent and not something to rely on for any
> vaguely-portable code.
libc++abi's unwind doesn't really support unwinding through signal
handlers, at least it wouldn't do anything special for them. I don't
have the faintest idea what the correct semantic would even be. Does it
restore the saved signal mask? Can you even unwind past the frame? In
general you won't as unwind instructions are not precise/

Joerg