Adding CFG edges for null pointer exceptions?

Hi,

Is it possible to add edges to the CFG from instructions that reference memory to exception landing pads? I want to do this so that I can convert SEGV signals into exceptions that can be safely unwound and caught. My compiler’s existing code generator handles this by having a combined memory dereference and jump on null instruction. LLVM doesn’t seem to have anything similar - I was thinking I might simulate this by adding a new instrinsic for potentially faulting memory references. Does anyone have any ideas on this?

Thanks,
– James

Hi James,

Is it possible to add edges to the CFG from instructions that reference memory to exception landing pads? I want to do this so that I can convert SEGV signals into exceptions that can be safely unwound and caught. My compiler's existing code generator handles this by having a combined memory dereference and jump on null instruction. LLVM doesn't seem to have anything similar - I was thinking I might simulate this by adding a new instrinsic for potentially faulting memory references. Does anyone have any ideas on this?

see http://llvm.org/PR1269 (support for non-call exceptions). If you are only
interested in null dereferences, I suggest you insert explicit checks for null
pointers for the moment, branching to a "throw" if one is found.

Ciao,

Duncan.

Hi James,

Is it possible to add edges to the CFG from instructions that reference memory to exception landing pads? I want to do this so that I can convert SEGV signals into exceptions that can be safely unwound and caught. My compiler’s existing code generator handles this by having a combined memory dereference and jump on null instruction. LLVM doesn’t seem to have anything similar - I was thinking I might simulate this by adding a new instrinsic for potentially faulting memory references. Does anyone have any ideas on this?

see http://llvm.org/PR1269 (support for non-call exceptions).

Thanks. That looks hairier than I anticipated!

If you are only
interested in null dereferences, I suggest you insert explicit checks for null
pointers for the moment, branching to a “throw” if one is found.

Yes - I was hoping to avoid gererating what’s basically a redundant check given that the hardware will trap anyway but I can’t think of a simple alternative.

It did occur to me that I might be able to avoid explicit null checks in functions without a null exception pointer handler because control would leave such a function completely if the SEGV handler generated a null pointer exception. This is assuming that the stack frame of such function containing null dereferences would be correctly unwound (which I’m not certain of).

I’d have to take care that functions without null checks were not inlined. Or better yet, generate the null checks for all functions and then selectively remove them from eligible functions after inlining is done. I could perhaps do this by adding a null check intrinsic that is lowered to either an explicit check + throw or to nothing depending on the presence of a specific call to llvm.eh.selector within the function.

– James

– James