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

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

On Wed, Apr 2, 2014 at 8:18 AM, Joerg Sonnenberger
<joerg at britannica.bec.de> wrote:
> 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
I've done a similar scheme in the past using Mach exception handlers.
Basically there's a thread running that gets told when bad memory
accesses happen and it has access to all of that thread's register
state. Given the state, it determines whether or not an exception
should be thrown (e.g. is the current instruction pointer is in user
code). Then it changes the thread's register state in order to push a
new stack frame and call the function that raises the exception. Once
all of the setup is done, the thread is resumed and things go on their
merry way without crashing.

I'd love to see this become feasible with LLVM as we found this a
significant win in terms of reducing binary size.

-- Joe Ranieri

On 04/02/2014 07:44 AM, Joe Ranieri wrote:
> On Wed, Apr 2, 2014 at 8:18 AM, Joerg Sonnenberger
> <joerg at britannica.bec.de> wrote:
>> 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
> I've done a similar scheme in the past using Mach exception handlers.
> Basically there's a thread running that gets told when bad memory
> accesses happen and it has access to all of that thread's register
> state. Given the state, it determines whether or not an exception
> should be thrown (e.g. is the current instruction pointer is in user
> code). Then it changes the thread's register state in order to push a
> new stack frame and call the function that raises the exception. Once
> all of the setup is done, the thread is resumed and things go on their
> merry way without crashing.
>
> I'd love to see this become feasible with LLVM as we found this a
> significant win in terms of reducing binary size.
Unless I'm misunderstanding, this is possible today and wouldn't be too 
hard to implement.

The trick is to preserve the control flow possibilities at the IR level 
so that there's a known exceptional resume point after the potentially 
faulting instruction.  Any potentially faulting operation could be 
represented as an invoke to a properly modelled intrinsic.

In SelectionDAGBuilder, you could emit the actual instructions rather 
than lowering the call part of the invoke normally.  (I think.  Haven't 
implemented that and this area is filled with corner cases...)

Philip