[PATCH 00/13] Request to merge Address Sanitizer in

[H.J. Lu]

On Thu, Nov 1, 2012 at 12:52 PM,  <dodji@redhat.com> wrote:
> From: Dodji Seketeli <dodji@seketeli.org>
>
> Hello,
>
> The set of patches following this message represents the work that
> happened on the asan branch to build up the Address Sanitizer work
> started in the Google branch.
>
> Address Sanitizer (aka asan) is a memory error detector.  It finds
> use-after-free and {heap,stack,global}-buffer overflow bugs in C/C++
> programs.
>
> One can learn about the way it works by reading the pdf slides at [1],
> or by reading the documentation on the wiki page of the project at [2].
>
> To make a long story short, it works by associating each memory region
> of eight consecutive bytes with a shadow byte that tells whether if
> each byte of the memory region is addressable or not.  So,
> conceptually, there is a function 'MemToShadow' which, for each set of
> contiguous eight bytes of memory returns a shadow byte that tells
> whether if each byte is accessible or not.
>
> Then, each memory access is instrumented by the asan pass to retrieve
> the shadow byte of the accessed memory; if the access is to a memory
> address that is deemed non-accessible, a call to an asan runtime
> library function is issued to report a meaningful error to the user,
> and the access is performed, letting the user program proceed despite
> the error.
>
> The advantage of this approach, compared to say, Valgrind[4] is the
> lower time and space overhead.  Eventually, when this tool becomes
> more solid, it'll become complementary to Valgrind.
>
> Apart from the compiler components, asan needs a runtime library to
> function.  We share that library with the LLVM implementation of asan
> that is described at [3].  The last patch of the set imports this
> library in its pristine form into our tree.  The plan is to regularly
> synchronize it with its LLVM upstream repository.
>
> On behalf of the GCC asan developers listed below, I am thus proposing
> these patches for inclusion into trunk.  I chose to follow the
> chronological commits that happened on the [asan] branch, to ease the
> authorship propagation.  Except for some few exceptions, each of these
> commits are reasonably logically atomic, so they hopefully shouldn't
> be too hard to review.
>
> The first patch is the initial import of the asan state from the
> Google branch into the [asan] branch.  Subsequent patches clean the
> code up, add features like protection of stack and global variables,
> instrumentation of memory access through built-in functions, and, last
> but not least, the import of the runtime library.
>
> Please note that the ChangeLog.asan is meant to disappear at commit
> time, as its content will be updated (for the dates) and prepended to
> the normal ChangeLog file.
>
> One noticeable shortcoming that we have at the moment is the lack of a
> DejaGNU test harness for this.  This is planned to be addressed as
> soon as possible.
>

Don't we need a bugzilla component for Sanitizer?

-- 
H.J.