On 1 February 2010 08:11, Duncan Sands <span dir="ltr"><<a href="mailto:baldrick@free.fr">baldrick@free.fr</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi James,<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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?<br>

</blockquote>
<br></div>
see <a href="http://llvm.org/PR1269" target="_blank">http://llvm.org/PR1269</a> (support for non-call exceptions).</blockquote><div>Thanks. That looks hairier than I anticipated!<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
If you are only<br>
interested in null dereferences, I suggest you insert explicit checks for null<br>
pointers for the moment, branching to a "throw" if one is found.<br></blockquote><div>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.<br>
<br>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).<br>
<br>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.<br>
<br>-- James<br><br>-- James<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Ciao,<br><font color="#888888">
<br>
Duncan.<br>
<br>
</font></blockquote></div><br>