llvm dev - Feb 2010 - [LLVMdev] 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100131/40a353a6/attachment.html>

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.

On 1 February 2010 08:11, Duncan Sands <baldrick at free.fr> wrote:
> 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

> Ciao,
>
> Duncan.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100201/b998da4a/attachment.html>