[LLVMdev] Adding CFG edges for null pointer exceptions?

James Williams junk at giantblob.com
Mon Feb 1 00:46:09 PST 2010


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>


More information about the llvm-dev mailing list