[LLVMdev] loads from a null address and optimizations

[Bill Wendling]

It's essentially the sane thing. :-) I don't quite understand the  
code. Is 'v' ever assigned a value before 'v.Call()'?

Two options remain, from what I can see. Either mark v as volatile, or  
compile without optimizations. The second is more drastic.

If you *really* want it to perform a call on null. Then you could  
place a function in another module that only returns null, then do the  
call:

// module A
typedef void (*func)();

func Foo() { return 0; }

// module B

Foo().Call();

And then make sure you don't perform LTO.

-bw

On Sep 5, 2009, at 4:59 PM, Zoltan Varga <vargaz at gmail.com> wrote:

> Hi,
>
>   I don't intentionally want to induce a tramp, the load null is  
> created by an llvm optimization
> pass from code like:
>    v = null;
>    .....
>    v.Call ();
>
>             Zoltan
>
> On Sat, Sep 5, 2009 at 11:39 PM, Bill Wendling <isanbard at gmail.com>  
> wrote:
> Hi Zoltan,
>
> We've come across this before where people meant to induce a trap by  
> dereferencing a null. It doesn't work for LLVM (as you found out).  
> Essentially, it's a valid transformation to turn this into  
> unreachable. The better solution is to use something like  
> __builtin_trap.
>
> -bw
>
>
> On Sep 5, 2009, at 2:19 PM, Zoltan Varga <vargaz at gmail.com> wrote:
>
>
>                Hi,
>
>  Currently, llvm treats the loads from a null address as unreachable  
> code, i.e.:
>     load i32* null
> is transformed by some optimization pass into
>    unreachable
>
> This presents problems in JIT compilers like mono which implement  
> null pointer checks by trapping SIGSEGV signals. It also
> looks incorrect since it changes program behavior, which might be  
> undefined in general, but it is quite well defined on unix.
> Is there a way to prevent llvm from doing this besides marking all  
> loads as volatile ?
>
>                          thanks
>
>                              Zoltan
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090905/91978212/attachment.html>