Getting ready to merge AddressSanitizer into trunk

[Xinliang David Li]

Asan functionality is almost complete. The only missing feature is the
handling of bit-fields. In addition there is the need for some option
and attribute change, but those are minor. I think it is now a good
time to merge the functionality into trunk.   After that, more
extensive testings can be done using SPEC, SPEC06, and open source
projects such Chrome, Mozilla etc.


On Mon, Oct 29, 2012 at 11:07 AM, Dodji Seketeli <dodji@redhat.com> wrote:
> 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?

Wei has run SPEC with asan, and found one bug with it which he
submitted the fix.  After it gets into trunk, more aggressive unit and
application testings will be done.

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


yes.


> * [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?

Yes, we were asked to make minor changes in the sources before dumping
them into the gcc tree. Assuming the runtime code is not changing
fast, we can probably live with that approach. If it becomes an issue
in the future, we can revisit the issue.


>
> * [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?


Bitfield access handling.

>
> * 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

Please do.

> 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?

Sounds good to me.


We also plan to get the ThreadSanitizer Feature into gcc-4.8.
According to koystya, there already exist a pretty complete
implementation, just need to adapt it to trunk and submit for review.

thanks,

David


>
> --
>                 Dodji