[LLVMdev] load widening conflicts with AddressSanitizer

Chris Lattner clattner at apple.com
Fri Dec 16 14:14:39 PST 2011

On Dec 16, 2011, at 12:39 PM, Kostya Serebryany wrote:
> > Do we consider the above transformation legal?

Yes, the transformation is perfectly legal for the normal compiler.

> > I would argue that it should not be legal.  We don't actually know what
> > comes after the 22 byte object.  Is it another memory object?  A
> > memory-mapped I/O device?  Unmapped memory?  Padded junk space?  Reading
> > memory-mapped I/O could have nasty side effects, and accessing unmapped
> > memory could cause the program to fault even though it was written correctly
> > as the source-language level.

Device memory accesses need to be done with volatile.  This can't cause a paging problem (e.g. causing an additional page fault where none existed before) on systems that use power-of-two sized pages.

> Having the load hit unmapped memory is impossible on common
> architectures given the alignment we're talking about here.  And if
> memory-mapped IO comes after the memory object, the object itself also
> has some sort of unusual semantics, so it should be using volatile
> loads anyway.
> Would would be the right way to disable load widening when AddressSanitizer (or SAFECode) is enabled? 

This is a good question.  Would it be possible for ASan to do its instrumentation earlier?  I supposed we could add a "do not widen" metadata hint on load instructions or something like that.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111216/eb6ac5a5/attachment.html>

More information about the llvm-dev mailing list