Getting ready to merge AddressSanitizer into trunk

[Dodji Seketeli <dodji at redhat dot com>]

Hello,

This message is just an excuse to kick off a discussion about how we
should proceed to prepare the merge of the AddressSanitizer branch
into trunk, as the not-yet known date of the stage1 closing seems to
be approaching fast now.

Here are some topics that I think would be interesting to discuss.

* [Testing]

It seems like we still lack a (good) test harness for asan.  Most (if
not all) of the patches we sent were tested by inspecting the gimple
and assembly output on testing some random input files.

So has anyone run this asan implementation on stronger inputs like
spec & co?

In any case, after 4.8 (or even after stage1) I guess we'll seriously
need to have a DejaGNU compatible test harness for asan.

* [Runtime library]

What are the remaining blocking issues holding us back from having the
runtime library be copied verbatim from its LLVM home to the GCC tree,
and been synced regularly starting from there?

* [Feature Parity]

The original plan was to get AddressSanitizer into a reasonably
mergeable state for 4.8, and then, work from there to achieve feature
parity in subsequent major releases.  Today, here is what I think is
the list of coarse grained features we have for the asan branch, for
x86 targets only:

 - Instrument access to stack and global memory
 - Instrument access to memory through builtin functions

I am not mentioning the runtime features as the runtime library is
shared with LLVM.

Am I missing something?

* From here to there.

Assuming all these topics gets consensus, I guess someone needs to
submit a set of logical patches representing the changes that happened
on the branch, for the official review of the branch prior to the
stage1 closing date.  I can help with doing that if no-ones steps up,
but then I'll need help from the various committers on the branch to
address the comments that will arise during the review.

What do you think?

-- 
		Dodji