[LLVMdev] load widening conflicts with AddressSanitizer

Kostya Serebryany kcc at google.com
Tue Jan 24 12:45:45 PST 2012


On Tue, Jan 24, 2012 at 12:31 PM, Duncan Sands <baldrick at free.fr> wrote:

> Hi Kostya,
>
>
>     As far as I can see the C and C++ standards are not relevant.  ASAN
>> works on
>>    LLVM IR, not on C or C++.  Lots of different languages have LLVM
>> frontends.  I
>>    personally turn Ada and Fortran into LLVM IR all the time for example.
>>  Clearly
>>    the C standard is not relevant to LLVM IR coming from such languages.
>>  What
>>    matters is how LLVM IR is defined.  As far as I know this construct is
>> perfectly
>>    valid in LLVM IR.
>>
>>
>> Asan will not work for Fortran and Ada anyway (at least, out of the box).
>> I am not even sure that anything like asan is needed for Ada (it has
>> bounds
>> checking built-in, the dynamic memory allocation is much more
>> restrictive).
>> The tool is rather specific to C/C++ (and ObjectiveC probably, although
>> we have
>> almost no tests for ObjectiveC, nor much knowledge in it).
>> Yes, the IR transformations are done on the LLVM level, but the asan
>> run-time
>> library heavily depends on the C/C++ semantics and even implementation,
>> and you can't really separate the asan instrumentation pass from the
>> run-time.
>>
>
> it's pretty disappointing to hear that asan is basically just for C.


If someone has use cases for other languages I'd like to hear about those.
In Fortran, asan is unlikely to be required because the language allows to
implement bounds checking simpler
(not sure about use-after-free for dynamic memory in Fortran 95). Ditto for
Ada, or e.g. Java.

--kcc

 But since
> it is, I won't bother you anymore about this attribute (though I still
> don't
> like it much).
>
> Ciao, Duncan.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120124/db3001a3/attachment.html>


More information about the llvm-dev mailing list