search for: fasan

...he LLVM suite that exercise the functionality independent of any > runtime so that other developers can catch regressions. Also, unittests in > the LLVM unittest tree would be nice as well. > Currently, I have tests<http://code.google.com/p/address-sanitizer/source/browse/#svn%2Ftrunk%2Fasan%2Ftests>that work only with the run-time library. I will definitely need tests that don't require run-time support. > > > Have you written a Clang patch to turn this functionality on and off? > Looking at the wiki documentation shows one thing that gives me pause: > you'...

...oking at the wiki documentation shows one thing that gives me pause: you're using the -mllvm flag in Clang to directly pass options down to the LLVM layer. Also, it indicates the asan functionality defaults to on. Ideally all of this functionality would default to off, and be enabled via '-fasan' or even better '-faddress-sanitizer' in Clang. That would match the behavior of '-fcatch-undefined-behavior', '-fmudflap', etc. If you want to expose the more fine grained flags to users that are mentioned on the wiki page, they could also have '-f...' Clang fla...

...ct from a generic 'runtimes' project. I'm not sure that this solves the problem. The reason we have dual licenses for the runtime stuff is that we don't want the UIUC license (which has a binary attribution clause) to affect stuff built with the compiler. Saying that "clang -fasan produces code that has to binary attribute the LLVM license" is pretty lame. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120531/c3a1ffb1/attachment.html>

...2012, at 6:48 PM, Chandler Carruth wrote: > I'm not sure that this solves the problem. The reason we have dual licenses for the runtime stuff is that we don't want the UIUC license (which has a binary attribution clause) to affect stuff built with the compiler. Saying that "clang -fasan produces code that has to binary attribute the LLVM license" is pretty lame. > > I think that what is *traditionally* thought of as compiler-rt has different needs from ASan/TSan/etc. The latter runtimes are really intended to be separate units from the binary; for example none of their...

On Thu, May 31, 2012 at 1:13 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > On 31 May 2012 05:02, Alexey Samsonov <samsonov at google.com> wrote: > > Hi, > > > > tl;dr How can I include LLVM headers and use code from libLLVM*.a files > when > > building compiler-rt libraries? > > LLVM and compiler-rt have different licenses

...th wrote: > > I'm not sure that this solves the problem. The reason we have dual >> licenses for the runtime stuff is that we don't want the UIUC license >> (which has a binary attribution clause) to affect stuff built with the >> compiler. Saying that "clang -fasan produces code that has to binary >> attribute the LLVM license" is pretty lame. >> > > I think that what is *traditionally* thought of as compiler-rt has > different needs from ASan/TSan/etc. The latter runtimes are really intended > to be separate units from the binary...

...s http://code.google.com/p/address-sanitizer/source/browse/trunk/llvm/AddressSanitizer.cpp . It instruments all memory accesses and inserts redzones around stack objects (around globals too, but this is unfinished). - Tiny patch to actually insert the instrumentation pass and to handle the "-fasan" flag in the driver. http://code.google.com/p/address-sanitizer/source/browse/trunk/llvm/clang.patch This patch is a bit outdated (applies to r130919) - The 'ignore' machinery is taken from the ThreadSanitizer project. This is basically a whitelist/blacklist by function name, file na...

...es' project. > > > I'm not sure that this solves the problem. The reason we have dual > licenses for the runtime stuff is that we don't want the UIUC license > (which has a binary attribution clause) to affect stuff built with the > compiler. Saying that "clang -fasan produces code that has to binary > attribute the LLVM license" is pretty lame. > I think that what is *traditionally* thought of as compiler-rt has different needs from ASan/TSan/etc. The latter runtimes are really intended to be separate units from the binary; for example none of their...

...er Carruth wrote: > >> I'm not sure that this solves the problem. The reason we have dual > licenses for the runtime stuff is that we don't want the UIUC license > (which has a binary attribution clause) to affect stuff built with the > compiler. Saying that "clang -fasan produces code that has to binary > attribute the LLVM license" is pretty lame. > >> > >> I think that what is *traditionally* thought of as compiler-rt has > different needs from ASan/TSan/etc. The latter runtimes are really intended > to be separate units from the b...

..., at 6:48 PM, Chandler Carruth wrote: >> I'm not sure that this solves the problem. The reason we have dual licenses for the runtime stuff is that we don't want the UIUC license (which has a binary attribution clause) to affect stuff built with the compiler. Saying that "clang -fasan produces code that has to binary attribute the LLVM license" is pretty lame. >> >> I think that what is *traditionally* thought of as compiler-rt has different needs from ASan/TSan/etc. The latter runtimes are really intended to be separate units from the binary; for example none...

...: >> >> I'm not sure that this solves the problem. The reason we have dual >> licenses for the runtime stuff is that we don't want the UIUC license >> (which has a binary attribution clause) to affect stuff built with the >> compiler. Saying that "clang -fasan produces code that has to binary >> attribute the LLVM license" is pretty lame. >> >> >> >> I think that what is *traditionally* thought of as compiler-rt has >> different needs from ASan/TSan/etc. The latter runtimes are really intended >> to be separ...

On Jun 16, 2011, at 1:27 AM, Kostya Serebryany wrote: > Hello again, > > The tool we announced 1.5 months ago has matured quite a bit. > In addition to heap out-of-bound and use-after-free bugs it also finds stack overruns/underruns. > AddressSanitizer is being actively used by the Chromium developers and already found over 20 bugs:

On Tue, Jul 26, 2011 at 10:20 AM, Chris Lattner <clattner at apple.com> wrote: > > On Jun 21, 2011, at 8:05 AM, Kostya Serebryany wrote: > > > Hi, > > What would be our next steps in getting ASan into the LLVM trunk? > > I'd like to do it in two steps, first for the LLVM part with minimal > tests and then for the run-time library and all tests. > >

On Jun 21, 2011, at 8:05 AM, Kostya Serebryany wrote: > Hi, > What would be our next steps in getting ASan into the LLVM trunk? > I'd like to do it in two steps, first for the LLVM part with minimal tests and then for the run-time library and all tests. > The current ASan's source repository will probably stay the primary home for the run-time library and tests as we plan

Hello again, The tool we announced 1.5 months ago has matured quite a bit. In addition to heap out-of-bound and use-after-free bugs it also finds stack overruns/underruns. AddressSanitizer is being actively used by the Chromium developers and already found over 20 bugs: http://blog.chromium.org/2011/06/testing-chromium-addresssanitizer-fast.html Question to the LLVM developers: would you