[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.
-Chris
-------------- 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