GCC KASAN patch

This patch adds AddressSanitizer for kernel instrumentation support to gcc (-fsanitize=kernel-address flag).

AddressSanitizer for kernel uses ThreadSanitizer pass (tsan.c) because the instrumentation is not finalized yet and we would like to have function calls instead of inlined instrumentation.

In future AddressSanitizer for Linux kernel will likely move to asan.c

[andreyknvl, 2013-10-02 09:31:39]

Please review.

[andreyknvl, 2013-10-02 10:58:33]

Please take a look at the comment in tsan.c

[kcc, 2013-10-02 11:00:16]

Add:
In future AddressSanitizer for Kernel will likely move to asan.c

On Wed, Oct 2, 2013 at 2:58 PM,  <andreyknvl@google.com> wrote:
> Please take a look at the comment in tsan.c
>
> https://codereview.appspot.com/14271043/

[andreyknvl, 2013-10-02 11:12:01]

Hi!

This is a patch that adds AddressSanitizer for kernel support to gcc.

Please review.

[davidxl, 2013-10-02 15:02:14]

Why not submitting it to GCC trunk first?  kcc@ and dmitry are the
project's maintainer in GCC.

David

On Wed, Oct 2, 2013 at 4:12 AM,  <andreyknvl@google.com> wrote:
> Hi!
>
> This is a patch that adds AddressSanitizer for kernel support to gcc.
>
> Please review.
>
> https://codereview.appspot.com/14271043/

[dvyukov, 2013-10-02 15:06:07]

We will, but we want internal pre-review first.


On Wed, Oct 2, 2013 at 7:02 PM, Xinliang David Li <davidxl@google.com> wrote:
> Why not submitting it to GCC trunk first?  kcc@ and dmitry are the
> project's maintainer in GCC.
>
> David
>
> On Wed, Oct 2, 2013 at 4:12 AM,  <andreyknvl@google.com> wrote:
>> Hi!
>>
>> This is a patch that adds AddressSanitizer for kernel support to gcc.
>>
>> Please review.
>>
>> https://codereview.appspot.com/14271043/

[davidxl, 2013-10-02 16:03:40]

https://codereview.appspot.com/14271043/diff/11001/gcc/toplev.c
File gcc/toplev.c (right):

https://codereview.appspot.com/14271043/diff/11001/gcc/toplev.c#newcode580
gcc/toplev.c:580: tsan_finish_file ();
WHen kernel address sanitizer is on, why not directly call
initialize_sanitizer_builtins? Calling tsan_finish_file for address sanitizer
looks weird.

https://codereview.appspot.com/14271043/diff/11001/gcc/tsan.c
File gcc/tsan.c (right):

https://codereview.appspot.com/14271043/diff/11001/gcc/tsan.c#newcode45
gcc/tsan.c:45: the instrumentation is not finalized yet and we would like to
have
I think this this is weird. It is better not mix address sanitizer code in
tsan.c.

https://codereview.appspot.com/14271043/diff/11001/gcc/tsan.c#newcode59
gcc/tsan.c:59: if ((flag_sanitize & SANITIZE_KERNEL_ADDRESS) == 0)
Will this work when both thread sanitizer and kernel address sanitizer are
specified?

https://codereview.appspot.com/14271043/diff/11001/gcc/tsan.c#newcode732
gcc/tsan.c:732: instrument_func_entry ();
Why not making instrument_func_entry etc extern and declare them in asan.h?

[vapier1, 2013-10-02 17:47:50]

https://codereview.appspot.com/14271043/diff/11001/gcc/doc/invoke.texi
File gcc/doc/invoke.texi (right):

https://codereview.appspot.com/14271043/diff/11001/gcc/doc/invoke.texi#newcod...
gcc/doc/invoke.texi:5235: Enable AddressSanitizer for Linux kernel, a fast
memory error detector.
i might drop the direct references to the Linux kernel.  any kernel/bootloader
can take advantage of this.

maybe phrase it:
Enable AddressSanitizer for bare metal systems (e.g. the Linux kernel), a fast
memory error detector.

https://codereview.appspot.com/14271043/diff/11001/gcc/flag-types.h
File gcc/flag-types.h (right):

https://codereview.appspot.com/14271043/diff/11001/gcc/flag-types.h#newcode208
gcc/flag-types.h:208: SANITIZE_KERNEL_ADDRESS = 1 << 1,
does the value matter ?  seems like it's normal to just append the list rather
than injecting it in the middle.

[dvyukov, 2013-10-08 17:42:40]

https://codereview.appspot.com/14271043/diff/11001/gcc/tsan.c
File gcc/tsan.c (right):

https://codereview.appspot.com/14271043/diff/11001/gcc/tsan.c#newcode45
gcc/tsan.c:45: the instrumentation is not finalized yet and we would like to
have
On 2013/10/02 16:03:41, davidxl wrote:
> I think this this is weird. It is better not mix address sanitizer code in
> tsan.c.

Yes, this is weird.
Eventually kasan will use asan instrumentation pass with some minimal changes.
But for now we want to get something into crosstool, so that it's available for
prodkernel and ChromeOS. Upstream gcc is nice but not particularly critical at
this point.
Taking into account that the current code is a temporal implementation, it's
unclear whether it makes sense to put a lot of effort into it.

https://codereview.appspot.com/14271043/diff/11001/gcc/tsan.c#newcode59
gcc/tsan.c:59: if ((flag_sanitize & SANITIZE_KERNEL_ADDRESS) == 0)
On 2013/10/02 16:03:41, davidxl wrote:
> Will this work when both thread sanitizer and kernel address sanitizer are
> specified?

asan, tsan and kasan are incompatible, you can not enable two of them
tsan and kasan are in particular incompatible -- will the resulting binary run
in user space of kernel space?

[bjanakiraman_google.com, 2013-10-08 20:03:07]

Hi Dmitry,
I don't understand 'temporal implementation'. Is this meant to be stop-gap,
and if yes, for how long?

Its great to have this functionality, but my preference is to get it
upstream. It is a big re-write, or are you more worried about the process
of upstreaming?

Thanks,
Bhaskar


On Tue, Oct 8, 2013 at 10:42 AM, <dvyukov@google.com> wrote:

>
>
https://codereview.appspot.**com/14271043/diff/11001/gcc/**tsan.c<https://cod...
> File gcc/tsan.c (right):
>
> https://codereview.appspot.**com/14271043/diff/11001/gcc/**
>
tsan.c#newcode45<https://codereview.appspot.com/14271043/diff/11001/gcc/tsan.c#newcode45>
> gcc/tsan.c:45: the instrumentation is not finalized yet and we would
> like to have
> On 2013/10/02 16:03:41, davidxl wrote:
>
>> I think this this is weird. It is better not mix address sanitizer
>>
> code in
>
>> tsan.c.
>>
>
> Yes, this is weird.
> Eventually kasan will use asan instrumentation pass with some minimal
> changes.
> But for now we want to get something into crosstool, so that it's
> available for prodkernel and ChromeOS. Upstream gcc is nice but not
> particularly critical at this point.
> Taking into account that the current code is a temporal implementation,
> it's unclear whether it makes sense to put a lot of effort into it.
>
>
> https://codereview.appspot.**com/14271043/diff/11001/gcc/**
>
tsan.c#newcode59<https://codereview.appspot.com/14271043/diff/11001/gcc/tsan.c#newcode59>
> gcc/tsan.c:59: if ((flag_sanitize & SANITIZE_KERNEL_ADDRESS) == 0)
> On 2013/10/02 16:03:41, davidxl wrote:
>
>> Will this work when both thread sanitizer and kernel address sanitizer
>>
> are
>
>> specified?
>>
>
> asan, tsan and kasan are incompatible, you can not enable two of them
> tsan and kasan are in particular incompatible -- will the resulting
> binary run in user space of kernel space?
>
>
https://codereview.appspot.**com/14271043/<https://codereview.appspot.com/142...
>

[andreyknvl, 2013-10-09 12:27:44]

Please review again.

https://codereview.appspot.com/14271043/diff/11001/gcc/doc/invoke.texi
File gcc/doc/invoke.texi (right):

https://codereview.appspot.com/14271043/diff/11001/gcc/doc/invoke.texi#newcod...
gcc/doc/invoke.texi:5235: Enable AddressSanitizer for Linux kernel, a fast
memory error detector.
On 2013/10/02 17:47:50, vapier1 wrote:
> i might drop the direct references to the Linux kernel.  any kernel/bootloader
> can take advantage of this.
> 
> maybe phrase it:
> Enable AddressSanitizer for bare metal systems (e.g. the Linux kernel), a fast
> memory error detector.

Done.

https://codereview.appspot.com/14271043/diff/11001/gcc/flag-types.h
File gcc/flag-types.h (right):

https://codereview.appspot.com/14271043/diff/11001/gcc/flag-types.h#newcode208
gcc/flag-types.h:208: SANITIZE_KERNEL_ADDRESS = 1 << 1,
On 2013/10/02 17:47:50, vapier1 wrote:
> does the value matter ?  seems like it's normal to just append the list rather
> than injecting it in the middle.

Done.

https://codereview.appspot.com/14271043/diff/11001/gcc/toplev.c
File gcc/toplev.c (right):

https://codereview.appspot.com/14271043/diff/11001/gcc/toplev.c#newcode580
gcc/toplev.c:580: tsan_finish_file ();
On 2013/10/02 16:03:41, davidxl wrote:
> WHen kernel address sanitizer is on, why not directly call
> initialize_sanitizer_builtins? Calling tsan_finish_file for address sanitizer
> looks weird.

Done.

https://codereview.appspot.com/14271043/diff/11001/gcc/tsan.c
File gcc/tsan.c (right):

https://codereview.appspot.com/14271043/diff/11001/gcc/tsan.c#newcode59
gcc/tsan.c:59: if ((flag_sanitize & SANITIZE_KERNEL_ADDRESS) == 0)
On 2013/10/02 16:03:41, davidxl wrote:
> Will this work when both thread sanitizer and kernel address sanitizer are
> specified?

Added an error message when both thread and kernel-address -fsanitize options
are specified (see gcc.c).

Done.

https://codereview.appspot.com/14271043/diff/11001/gcc/tsan.c#newcode732
gcc/tsan.c:732: instrument_func_entry ();
On 2013/10/02 16:03:41, davidxl wrote:
> Why not making instrument_func_entry etc extern and declare them in asan.h?

I don't think I understand your suggestion, could you explain it in more
details?

[dvyukov, 2013-10-10 12:02:40]

On 2013/10/08 20:03:07, bjanakiraman_google.com wrote:
> Hi Dmitry,
> I don't understand 'temporal implementation'. Is this meant to be stop-gap,
> and if yes, for how long?


Yes, this is a stop-gap.
It's difficult to say for how long exactly. We want to hire a new developer for
this project (which may happen next week), and then there will be several
potential directions: improve runtime, deployment into prodkernel/ChromeOS,
replace the stop-gap compiler instrumentation with the final one.
I would say it can be 1-6 months or so.



> Its great to have this functionality, but my preference is to get it
> upstream. It is a big re-write, or are you more worried about the process
> of upstreaming?


I am more worried that it's a stop-gap solution, but at the same time we want
this in crosstool ASAP.



> On Tue, Oct 8, 2013 at 10:42 AM, <mailto:dvyukov@google.com> wrote:
> 
> >
> >
>
https://codereview.appspot.**com/14271043/diff/11001/gcc/**tsan.c%3Chttps://c...>
> > File gcc/tsan.c (right):
> >
> > https://codereview.appspot.**com/14271043/diff/11001/gcc/**
> >
>
tsan.c#newcode45<https://codereview.appspot.com/14271043/diff/11001/gcc/tsan.c#newcode45>
> > gcc/tsan.c:45: the instrumentation is not finalized yet and we would
> > like to have
> > On 2013/10/02 16:03:41, davidxl wrote:
> >
> >> I think this this is weird. It is better not mix address sanitizer
> >>
> > code in
> >
> >> tsan.c.
> >>
> >
> > Yes, this is weird.
> > Eventually kasan will use asan instrumentation pass with some minimal
> > changes.
> > But for now we want to get something into crosstool, so that it's
> > available for prodkernel and ChromeOS. Upstream gcc is nice but not
> > particularly critical at this point.
> > Taking into account that the current code is a temporal implementation,
> > it's unclear whether it makes sense to put a lot of effort into it.
> >
> >
> > https://codereview.appspot.**com/14271043/diff/11001/gcc/**
> >
>
tsan.c#newcode59<https://codereview.appspot.com/14271043/diff/11001/gcc/tsan.c#newcode59>
> > gcc/tsan.c:59: if ((flag_sanitize & SANITIZE_KERNEL_ADDRESS) == 0)
> > On 2013/10/02 16:03:41, davidxl wrote:
> >
> >> Will this work when both thread sanitizer and kernel address sanitizer
> >>
> > are
> >
> >> specified?
> >>
> >
> > asan, tsan and kasan are incompatible, you can not enable two of them
> > tsan and kasan are in particular incompatible -- will the resulting
> > binary run in user space of kernel space?
> >
> >
>
https://codereview.appspot.**com/14271043/%3Chttps://codereview.appspot.com/1...>
> >

[davidxl, 2013-10-10 18:18:30]

The change is ok for Google v17 branch for now.

David

On Thu, Oct 10, 2013 at 5:02 AM,  <dvyukov@google.com> wrote:
> On 2013/10/08 20:03:07, bjanakiraman_google.com wrote:
>>
>> Hi Dmitry,
>> I don't understand 'temporal implementation'. Is this meant to be
>
> stop-gap,
>>
>> and if yes, for how long?
>
>
>
> Yes, this is a stop-gap.
> It's difficult to say for how long exactly. We want to hire a new
> developer for this project (which may happen next week), and then there
> will be several potential directions: improve runtime, deployment into
> prodkernel/ChromeOS, replace the stop-gap compiler instrumentation with
> the final one.
> I would say it can be 1-6 months or so.
>
>
>
>
>> Its great to have this functionality, but my preference is to get it
>> upstream. It is a big re-write, or are you more worried about the
>
> process
>>
>> of upstreaming?
>
>
>
> I am more worried that it's a stop-gap solution, but at the same time we
> want this in crosstool ASAP.
>
>
>
>> On Tue, Oct 8, 2013 at 10:42 AM, <mailto:dvyukov@google.com> wrote:
>
>
>> >
>> >
>
>
>
https://codereview.appspot.**com/14271043/diff/11001/gcc/**tsan.c%3Chttps://c...>
>>
>> > File gcc/tsan.c (right):
>> >
>> > https://codereview.appspot.**com/14271043/diff/11001/gcc/**
>> >
>
>
>
tsan.c#newcode45<https://codereview.appspot.com/14271043/diff/11001/gcc/tsan.c#newcode45>
>>
>> > gcc/tsan.c:45: the instrumentation is not finalized yet and we would
>> > like to have
>> > On 2013/10/02 16:03:41, davidxl wrote:
>> >
>> >> I think this this is weird. It is better not mix address sanitizer
>> >>
>> > code in
>> >
>> >> tsan.c.
>> >>
>> >
>> > Yes, this is weird.
>> > Eventually kasan will use asan instrumentation pass with some
>
> minimal
>>
>> > changes.
>> > But for now we want to get something into crosstool, so that it's
>> > available for prodkernel and ChromeOS. Upstream gcc is nice but not
>> > particularly critical at this point.
>> > Taking into account that the current code is a temporal
>
> implementation,
>>
>> > it's unclear whether it makes sense to put a lot of effort into it.
>> >
>> >
>> > https://codereview.appspot.**com/14271043/diff/11001/gcc/**
>> >
>
>
>
tsan.c#newcode59<https://codereview.appspot.com/14271043/diff/11001/gcc/tsan.c#newcode59>
>
>> > gcc/tsan.c:59: if ((flag_sanitize & SANITIZE_KERNEL_ADDRESS) == 0)
>> > On 2013/10/02 16:03:41, davidxl wrote:
>> >
>> >> Will this work when both thread sanitizer and kernel address
>
> sanitizer
>>
>> >>
>> > are
>> >
>> >> specified?
>> >>
>> >
>>
>> > asan, tsan and kasan are incompatible, you can not enable two of
>
> them
>>
>> > tsan and kasan are in particular incompatible -- will the resulting
>> > binary run in user space of kernel space?
>> >
>> >
>
>
>
https://codereview.appspot.**com/14271043/%3Chttps://codereview.appspot.com/1...>
>>
>> >
>
>
>
>
> https://codereview.appspot.com/14271043/

[preobr, 2014-03-26 18:55:02]

Hi,

we are interested in submitting this change to crosstool.
Should we go through another review or just rebase and submit?

Where is Google v17 branch?

Alexey

On 2013/10/10 18:18:30, davidxl wrote:
> The change is ok for Google v17 branch for now.
> 
> David
> 
> On Thu, Oct 10, 2013 at 5:02 AM,  <mailto:dvyukov@google.com> wrote:
> > On 2013/10/08 20:03:07, http://bjanakiraman_google.com wrote:
> >>
> >> Hi Dmitry,
> >> I don't understand 'temporal implementation'. Is this meant to be
> >
> > stop-gap,
> >>
> >> and if yes, for how long?
> >
> >
> >
> > Yes, this is a stop-gap.
> > It's difficult to say for how long exactly. We want to hire a new
> > developer for this project (which may happen next week), and then there
> > will be several potential directions: improve runtime, deployment into
> > prodkernel/ChromeOS, replace the stop-gap compiler instrumentation with
> > the final one.
> > I would say it can be 1-6 months or so.
> >
> >
> >
> >
> >> Its great to have this functionality, but my preference is to get it
> >> upstream. It is a big re-write, or are you more worried about the
> >
> > process
> >>
> >> of upstreaming?
> >
> >
> >
> > I am more worried that it's a stop-gap solution, but at the same time we
> > want this in crosstool ASAP.
> >
> >
> >
> >> On Tue, Oct 8, 2013 at 10:42 AM, <mailto:dvyukov@google.com> wrote:
> >
> >
> >> >
> >> >
> >
> >
> >
>
https://codereview.appspot.**com/14271043/diff/11001/gcc/**tsan.c%3Chttps://c...>
> >>
> >> > File gcc/tsan.c (right):
> >> >
> >> > https://codereview.appspot.**com/14271043/diff/11001/gcc/**
> >> >
> >
> >
> >
>
tsan.c#newcode45<https://codereview.appspot.com/14271043/diff/11001/gcc/tsan.c#newcode45>
> >>
> >> > gcc/tsan.c:45: the instrumentation is not finalized yet and we would
> >> > like to have
> >> > On 2013/10/02 16:03:41, davidxl wrote:
> >> >
> >> >> I think this this is weird. It is better not mix address sanitizer
> >> >>
> >> > code in
> >> >
> >> >> tsan.c.
> >> >>
> >> >
> >> > Yes, this is weird.
> >> > Eventually kasan will use asan instrumentation pass with some
> >
> > minimal
> >>
> >> > changes.
> >> > But for now we want to get something into crosstool, so that it's
> >> > available for prodkernel and ChromeOS. Upstream gcc is nice but not
> >> > particularly critical at this point.
> >> > Taking into account that the current code is a temporal
> >
> > implementation,
> >>
> >> > it's unclear whether it makes sense to put a lot of effort into it.
> >> >
> >> >
> >> > https://codereview.appspot.**com/14271043/diff/11001/gcc/**
> >> >
> >
> >
> >
>
tsan.c#newcode59<https://codereview.appspot.com/14271043/diff/11001/gcc/tsan.c#newcode59>
> >
> >> > gcc/tsan.c:59: if ((flag_sanitize & SANITIZE_KERNEL_ADDRESS) == 0)
> >> > On 2013/10/02 16:03:41, davidxl wrote:
> >> >
> >> >> Will this work when both thread sanitizer and kernel address
> >
> > sanitizer
> >>
> >> >>
> >> > are
> >> >
> >> >> specified?
> >> >>
> >> >
> >>
> >> > asan, tsan and kasan are incompatible, you can not enable two of
> >
> > them
> >>
> >> > tsan and kasan are in particular incompatible -- will the resulting
> >> > binary run in user space of kernel space?
> >> >
> >> >
> >
> >
> >
>
https://codereview.appspot.**com/14271043/%3Chttps://codereview.appspot.com/1...>
> >>
> >> >
> >
> >
> >
> >
> > https://codereview.appspot.com/14271043/

[davidxl, 2014-03-26 18:57:04]

Please submit another one to gcc-patches@, cc Dmitry and me.

thanks,

David

On Wed, Mar 26, 2014 at 11:55 AM,  <preobr@google.com> wrote:
> Hi,
>
> we are interested in submitting this change to crosstool.
> Should we go through another review or just rebase and submit?
>
> Where is Google v17 branch?
>
> Alexey
>
> On 2013/10/10 18:18:30, davidxl wrote:
>>
>> The change is ok for Google v17 branch for now.
>
>
>> David
>
>
>> On Thu, Oct 10, 2013 at 5:02 AM,  <mailto:dvyukov@google.com> wrote:
>> > On 2013/10/08 20:03:07, http://bjanakiraman_google.com wrote:
>> >>
>> >> Hi Dmitry,
>> >> I don't understand 'temporal implementation'. Is this meant to be
>> >
>> > stop-gap,
>> >>
>> >> and if yes, for how long?
>> >
>> >
>> >
>> > Yes, this is a stop-gap.
>> > It's difficult to say for how long exactly. We want to hire a new
>> > developer for this project (which may happen next week), and then
>
> there
>>
>> > will be several potential directions: improve runtime, deployment
>
> into
>>
>> > prodkernel/ChromeOS, replace the stop-gap compiler instrumentation
>
> with
>>
>> > the final one.
>> > I would say it can be 1-6 months or so.
>> >
>> >
>> >
>> >
>> >> Its great to have this functionality, but my preference is to get
>
> it
>>
>> >> upstream. It is a big re-write, or are you more worried about the
>> >
>> > process
>> >>
>> >> of upstreaming?
>> >
>> >
>> >
>> > I am more worried that it's a stop-gap solution, but at the same
>
> time we
>>
>> > want this in crosstool ASAP.
>> >
>> >
>> >
>> >> On Tue, Oct 8, 2013 at 10:42 AM, <mailto:dvyukov@google.com> wrote:
>> >
>> >
>> >> >
>> >> >
>> >
>> >
>> >
>
>
>
https://codereview.appspot.**com/14271043/diff/11001/gcc/**tsan.c%3Chttps://c...>
>>
>> >>
>> >> > File gcc/tsan.c (right):
>> >> >
>> >> > https://codereview.appspot.**com/14271043/diff/11001/gcc/**
>> >> >
>> >
>> >
>> >
>
>
>
tsan.c#newcode45<https://codereview.appspot.com/14271043/diff/11001/gcc/tsan.c#newcode45>
>>
>> >>
>> >> > gcc/tsan.c:45: the instrumentation is not finalized yet and we
>
> would
>>
>> >> > like to have
>> >> > On 2013/10/02 16:03:41, davidxl wrote:
>> >> >
>> >> >> I think this this is weird. It is better not mix address
>
> sanitizer
>>
>> >> >>
>> >> > code in
>> >> >
>> >> >> tsan.c.
>> >> >>
>> >> >
>> >> > Yes, this is weird.
>> >> > Eventually kasan will use asan instrumentation pass with some
>> >
>> > minimal
>> >>
>> >> > changes.
>> >> > But for now we want to get something into crosstool, so that it's
>> >> > available for prodkernel and ChromeOS. Upstream gcc is nice but
>
> not
>>
>> >> > particularly critical at this point.
>> >> > Taking into account that the current code is a temporal
>> >
>> > implementation,
>> >>
>> >> > it's unclear whether it makes sense to put a lot of effort into
>
> it.
>>
>> >> >
>> >> >
>> >> > https://codereview.appspot.**com/14271043/diff/11001/gcc/**
>> >> >
>> >
>> >
>> >
>
>
>
tsan.c#newcode59<https://codereview.appspot.com/14271043/diff/11001/gcc/tsan.c#newcode59>
>>
>> >
>> >> > gcc/tsan.c:59: if ((flag_sanitize & SANITIZE_KERNEL_ADDRESS) ==
>
> 0)
>>
>> >> > On 2013/10/02 16:03:41, davidxl wrote:
>> >> >
>> >> >> Will this work when both thread sanitizer and kernel address
>> >
>> > sanitizer
>> >>
>> >> >>
>> >> > are
>> >> >
>> >> >> specified?
>> >> >>
>> >> >
>> >>
>> >> > asan, tsan and kasan are incompatible, you can not enable two of
>> >
>> > them
>> >>
>> >> > tsan and kasan are in particular incompatible -- will the
>
> resulting
>>
>> >> > binary run in user space of kernel space?
>> >> >
>> >> >
>> >
>> >
>> >
>
>
>
https://codereview.appspot.**com/14271043/%3Chttps://codereview.appspot.com/1...>
>>
>> >>
>> >> >
>> >
>> >
>> >
>> >
>> > https://codereview.appspot.com/14271043/
>
>
>
> https://codereview.appspot.com/14271043/

[dvyukov, 2014-03-26 18:59:57]

What branch do we need to use as base now?


On Wed, Mar 26, 2014 at 10:57 PM, Xinliang David Li <davidxl@google.com> wrote:
> Please submit another one to gcc-patches@, cc Dmitry and me.
>
> thanks,
>
> David
>
> On Wed, Mar 26, 2014 at 11:55 AM,  <preobr@google.com> wrote:
>> Hi,
>>
>> we are interested in submitting this change to crosstool.
>> Should we go through another review or just rebase and submit?
>>
>> Where is Google v17 branch?
>>
>> Alexey
>>
>> On 2013/10/10 18:18:30, davidxl wrote:
>>>
>>> The change is ok for Google v17 branch for now.
>>
>>
>>> David
>>
>>
>>> On Thu, Oct 10, 2013 at 5:02 AM,  <mailto:dvyukov@google.com> wrote:
>>> > On 2013/10/08 20:03:07, http://bjanakiraman_google.com wrote:
>>> >>
>>> >> Hi Dmitry,
>>> >> I don't understand 'temporal implementation'. Is this meant to be
>>> >
>>> > stop-gap,
>>> >>
>>> >> and if yes, for how long?
>>> >
>>> >
>>> >
>>> > Yes, this is a stop-gap.
>>> > It's difficult to say for how long exactly. We want to hire a new
>>> > developer for this project (which may happen next week), and then
>>
>> there
>>>
>>> > will be several potential directions: improve runtime, deployment
>>
>> into
>>>
>>> > prodkernel/ChromeOS, replace the stop-gap compiler instrumentation
>>
>> with
>>>
>>> > the final one.
>>> > I would say it can be 1-6 months or so.
>>> >
>>> >
>>> >
>>> >
>>> >> Its great to have this functionality, but my preference is to get
>>
>> it
>>>
>>> >> upstream. It is a big re-write, or are you more worried about the
>>> >
>>> > process
>>> >>
>>> >> of upstreaming?
>>> >
>>> >
>>> >
>>> > I am more worried that it's a stop-gap solution, but at the same
>>
>> time we
>>>
>>> > want this in crosstool ASAP.
>>> >
>>> >
>>> >
>>> >> On Tue, Oct 8, 2013 at 10:42 AM, <mailto:dvyukov@google.com> wrote:
>>> >
>>> >
>>> >> >
>>> >> >
>>> >
>>> >
>>> >
>>
>>
>>
https://codereview.appspot.**com/14271043/diff/11001/gcc/**tsan.c%3Chttps://c...>
>>>
>>> >>
>>> >> > File gcc/tsan.c (right):
>>> >> >
>>> >> > https://codereview.appspot.**com/14271043/diff/11001/gcc/**
>>> >> >
>>> >
>>> >
>>> >
>>
>>
>>
tsan.c#newcode45<https://codereview.appspot.com/14271043/diff/11001/gcc/tsan.c#newcode45>
>>>
>>> >>
>>> >> > gcc/tsan.c:45: the instrumentation is not finalized yet and we
>>
>> would
>>>
>>> >> > like to have
>>> >> > On 2013/10/02 16:03:41, davidxl wrote:
>>> >> >
>>> >> >> I think this this is weird. It is better not mix address
>>
>> sanitizer
>>>
>>> >> >>
>>> >> > code in
>>> >> >
>>> >> >> tsan.c.
>>> >> >>
>>> >> >
>>> >> > Yes, this is weird.
>>> >> > Eventually kasan will use asan instrumentation pass with some
>>> >
>>> > minimal
>>> >>
>>> >> > changes.
>>> >> > But for now we want to get something into crosstool, so that it's
>>> >> > available for prodkernel and ChromeOS. Upstream gcc is nice but
>>
>> not
>>>
>>> >> > particularly critical at this point.
>>> >> > Taking into account that the current code is a temporal
>>> >
>>> > implementation,
>>> >>
>>> >> > it's unclear whether it makes sense to put a lot of effort into
>>
>> it.
>>>
>>> >> >
>>> >> >
>>> >> > https://codereview.appspot.**com/14271043/diff/11001/gcc/**
>>> >> >
>>> >
>>> >
>>> >
>>
>>
>>
tsan.c#newcode59<https://codereview.appspot.com/14271043/diff/11001/gcc/tsan.c#newcode59>
>>>
>>> >
>>> >> > gcc/tsan.c:59: if ((flag_sanitize & SANITIZE_KERNEL_ADDRESS) ==
>>
>> 0)
>>>
>>> >> > On 2013/10/02 16:03:41, davidxl wrote:
>>> >> >
>>> >> >> Will this work when both thread sanitizer and kernel address
>>> >
>>> > sanitizer
>>> >>
>>> >> >>
>>> >> > are
>>> >> >
>>> >> >> specified?
>>> >> >>
>>> >> >
>>> >>
>>> >> > asan, tsan and kasan are incompatible, you can not enable two of
>>> >
>>> > them
>>> >>
>>> >> > tsan and kasan are in particular incompatible -- will the
>>
>> resulting
>>>
>>> >> > binary run in user space of kernel space?
>>> >> >
>>> >> >
>>> >
>>> >
>>> >
>>
>>
>>
https://codereview.appspot.**com/14271043/%3Chttps://codereview.appspot.com/1...>
>>>
>>> >>
>>> >> >
>>> >
>>> >
>>> >
>>> >
>>> > https://codereview.appspot.com/14271043/
>>
>>
>>
>> https://codereview.appspot.com/14271043/

[davidxl, 2014-03-26 19:01:48]

still google/gcc-4_8.

The subject line should starts with [GOOGLE]:

thanks,

David

On Wed, Mar 26, 2014 at 11:59 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
> What branch do we need to use as base now?
>
>
> On Wed, Mar 26, 2014 at 10:57 PM, Xinliang David Li <davidxl@google.com>
wrote:
>> Please submit another one to gcc-patches@, cc Dmitry and me.
>>
>> thanks,
>>
>> David
>>
>> On Wed, Mar 26, 2014 at 11:55 AM,  <preobr@google.com> wrote:
>>> Hi,
>>>
>>> we are interested in submitting this change to crosstool.
>>> Should we go through another review or just rebase and submit?
>>>
>>> Where is Google v17 branch?
>>>
>>> Alexey
>>>
>>> On 2013/10/10 18:18:30, davidxl wrote:
>>>>
>>>> The change is ok for Google v17 branch for now.
>>>
>>>
>>>> David
>>>
>>>
>>>> On Thu, Oct 10, 2013 at 5:02 AM,  <mailto:dvyukov@google.com> wrote:
>>>> > On 2013/10/08 20:03:07, http://bjanakiraman_google.com wrote:
>>>> >>
>>>> >> Hi Dmitry,
>>>> >> I don't understand 'temporal implementation'. Is this meant to be
>>>> >
>>>> > stop-gap,
>>>> >>
>>>> >> and if yes, for how long?
>>>> >
>>>> >
>>>> >
>>>> > Yes, this is a stop-gap.
>>>> > It's difficult to say for how long exactly. We want to hire a new
>>>> > developer for this project (which may happen next week), and then
>>>
>>> there
>>>>
>>>> > will be several potential directions: improve runtime, deployment
>>>
>>> into
>>>>
>>>> > prodkernel/ChromeOS, replace the stop-gap compiler instrumentation
>>>
>>> with
>>>>
>>>> > the final one.
>>>> > I would say it can be 1-6 months or so.
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >> Its great to have this functionality, but my preference is to get
>>>
>>> it
>>>>
>>>> >> upstream. It is a big re-write, or are you more worried about the
>>>> >
>>>> > process
>>>> >>
>>>> >> of upstreaming?
>>>> >
>>>> >
>>>> >
>>>> > I am more worried that it's a stop-gap solution, but at the same
>>>
>>> time we
>>>>
>>>> > want this in crosstool ASAP.
>>>> >
>>>> >
>>>> >
>>>> >> On Tue, Oct 8, 2013 at 10:42 AM, <mailto:dvyukov@google.com> wrote:
>>>> >
>>>> >
>>>> >> >
>>>> >> >
>>>> >
>>>> >
>>>> >
>>>
>>>
>>>
https://codereview.appspot.**com/14271043/diff/11001/gcc/**tsan.c%3Chttps://c...>
>>>>
>>>> >>
>>>> >> > File gcc/tsan.c (right):
>>>> >> >
>>>> >> > https://codereview.appspot.**com/14271043/diff/11001/gcc/**
>>>> >> >
>>>> >
>>>> >
>>>> >
>>>
>>>
>>>
tsan.c#newcode45<https://codereview.appspot.com/14271043/diff/11001/gcc/tsan.c#newcode45>
>>>>
>>>> >>
>>>> >> > gcc/tsan.c:45: the instrumentation is not finalized yet and we
>>>
>>> would
>>>>
>>>> >> > like to have
>>>> >> > On 2013/10/02 16:03:41, davidxl wrote:
>>>> >> >
>>>> >> >> I think this this is weird. It is better not mix address
>>>
>>> sanitizer
>>>>
>>>> >> >>
>>>> >> > code in
>>>> >> >
>>>> >> >> tsan.c.
>>>> >> >>
>>>> >> >
>>>> >> > Yes, this is weird.
>>>> >> > Eventually kasan will use asan instrumentation pass with some
>>>> >
>>>> > minimal
>>>> >>
>>>> >> > changes.
>>>> >> > But for now we want to get something into crosstool, so that it's
>>>> >> > available for prodkernel and ChromeOS. Upstream gcc is nice but
>>>
>>> not
>>>>
>>>> >> > particularly critical at this point.
>>>> >> > Taking into account that the current code is a temporal
>>>> >
>>>> > implementation,
>>>> >>
>>>> >> > it's unclear whether it makes sense to put a lot of effort into
>>>
>>> it.
>>>>
>>>> >> >
>>>> >> >
>>>> >> > https://codereview.appspot.**com/14271043/diff/11001/gcc/**
>>>> >> >
>>>> >
>>>> >
>>>> >
>>>
>>>
>>>
tsan.c#newcode59<https://codereview.appspot.com/14271043/diff/11001/gcc/tsan.c#newcode59>
>>>>
>>>> >
>>>> >> > gcc/tsan.c:59: if ((flag_sanitize & SANITIZE_KERNEL_ADDRESS) ==
>>>
>>> 0)
>>>>
>>>> >> > On 2013/10/02 16:03:41, davidxl wrote:
>>>> >> >
>>>> >> >> Will this work when both thread sanitizer and kernel address
>>>> >
>>>> > sanitizer
>>>> >>
>>>> >> >>
>>>> >> > are
>>>> >> >
>>>> >> >> specified?
>>>> >> >>
>>>> >> >
>>>> >>
>>>> >> > asan, tsan and kasan are incompatible, you can not enable two of
>>>> >
>>>> > them
>>>> >>
>>>> >> > tsan and kasan are in particular incompatible -- will the
>>>
>>> resulting
>>>>
>>>> >> > binary run in user space of kernel space?
>>>> >> >
>>>> >> >
>>>> >
>>>> >
>>>> >
>>>
>>>
>>>
https://codereview.appspot.**com/14271043/%3Chttps://codereview.appspot.com/1...>
>>>>
>>>> >>
>>>> >> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > https://codereview.appspot.com/14271043/
>>>
>>>
>>>
>>> https://codereview.appspot.com/14271043/

[preobr, 2014-03-26 19:20:50]

This patch will not fit on top of google/gcc-4_8
(it modifies enum sanitize_code in gcc/flag-types.h, which is not present
in google/gcc-4_8).

Should I base it on google/gcc-4_9 or google/main?

On Wed, Mar 26, 2014 at 11:01 PM, Xinliang David Li <davidxl@google.com>wrote:

> still google/gcc-4_8.
>
> The subject line should starts with [GOOGLE]:
>
> thanks,
>
> David
>
> On Wed, Mar 26, 2014 at 11:59 AM, Dmitry Vyukov <dvyukov@google.com>
> wrote:
> > What branch do we need to use as base now?
> >
> >
> > On Wed, Mar 26, 2014 at 10:57 PM, Xinliang David Li <davidxl@google.com>
> wrote:
> >> Please submit another one to gcc-patches@, cc Dmitry and me.
> >>
> >> thanks,
> >>
> >> David
> >>
> >> On Wed, Mar 26, 2014 at 11:55 AM,  <preobr@google.com> wrote:
> >>> Hi,
> >>>
> >>> we are interested in submitting this change to crosstool.
> >>> Should we go through another review or just rebase and submit?
> >>>
> >>> Where is Google v17 branch?
> >>>
> >>> Alexey
> >>>
> >>> On 2013/10/10 18:18:30, davidxl wrote:
> >>>>
> >>>> The change is ok for Google v17 branch for now.
> >>>
> >>>
> >>>> David
> >>>
> >>>
> >>>> On Thu, Oct 10, 2013 at 5:02 AM,  <mailto:dvyukov@google.com> wrote:
> >>>> > On 2013/10/08 20:03:07, http://bjanakiraman_google.com wrote:
> >>>> >>
> >>>> >> Hi Dmitry,
> >>>> >> I don't understand 'temporal implementation'. Is this meant to be
> >>>> >
> >>>> > stop-gap,
> >>>> >>
> >>>> >> and if yes, for how long?
> >>>> >
> >>>> >
> >>>> >
> >>>> > Yes, this is a stop-gap.
> >>>> > It's difficult to say for how long exactly. We want to hire a new
> >>>> > developer for this project (which may happen next week), and then
> >>>
> >>> there
> >>>>
> >>>> > will be several potential directions: improve runtime, deployment
> >>>
> >>> into
> >>>>
> >>>> > prodkernel/ChromeOS, replace the stop-gap compiler instrumentation
> >>>
> >>> with
> >>>>
> >>>> > the final one.
> >>>> > I would say it can be 1-6 months or so.
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> >> Its great to have this functionality, but my preference is to get
> >>>
> >>> it
> >>>>
> >>>> >> upstream. It is a big re-write, or are you more worried about the
> >>>> >
> >>>> > process
> >>>> >>
> >>>> >> of upstreaming?
> >>>> >
> >>>> >
> >>>> >
> >>>> > I am more worried that it's a stop-gap solution, but at the same
> >>>
> >>> time we
> >>>>
> >>>> > want this in crosstool ASAP.
> >>>> >
> >>>> >
> >>>> >
> >>>> >> On Tue, Oct 8, 2013 at 10:42 AM, <mailto:dvyukov@google.com>
> wrote:
> >>>> >
> >>>> >
> >>>> >> >
> >>>> >> >
> >>>> >
> >>>> >
> >>>> >
> >>>
> >>>
> >>> https://codereview.appspot.
> **com/14271043/diff/11001/gcc/**tsan.c%3Chttps://
> codereview.appspot.com/14271043/diff/11001/gcc/tsan.c>
> >>>>
> >>>> >>
> >>>> >> > File gcc/tsan.c (right):
> >>>> >> >
> >>>> >> > https://codereview.appspot.**com/14271043/diff/11001/gcc/**
> >>>> >> >
> >>>> >
> >>>> >
> >>>> >
> >>>
> >>>
> >>> tsan.c#newcode45<
> https://codereview.appspot.com/14271043/diff/11001/gcc/tsan.c#newcode45>
> >>>>
> >>>> >>
> >>>> >> > gcc/tsan.c:45: the instrumentation is not finalized yet and we
> >>>
> >>> would
> >>>>
> >>>> >> > like to have
> >>>> >> > On 2013/10/02 16:03:41, davidxl wrote:
> >>>> >> >
> >>>> >> >> I think this this is weird. It is better not mix address
> >>>
> >>> sanitizer
> >>>>
> >>>> >> >>
> >>>> >> > code in
> >>>> >> >
> >>>> >> >> tsan.c.
> >>>> >> >>
> >>>> >> >
> >>>> >> > Yes, this is weird.
> >>>> >> > Eventually kasan will use asan instrumentation pass with some
> >>>> >
> >>>> > minimal
> >>>> >>
> >>>> >> > changes.
> >>>> >> > But for now we want to get something into crosstool, so that it's
> >>>> >> > available for prodkernel and ChromeOS. Upstream gcc is nice but
> >>>
> >>> not
> >>>>
> >>>> >> > particularly critical at this point.
> >>>> >> > Taking into account that the current code is a temporal
> >>>> >
> >>>> > implementation,
> >>>> >>
> >>>> >> > it's unclear whether it makes sense to put a lot of effort into
> >>>
> >>> it.
> >>>>
> >>>> >> >
> >>>> >> >
> >>>> >> > https://codereview.appspot.**com/14271043/diff/11001/gcc/**
> >>>> >> >
> >>>> >
> >>>> >
> >>>> >
> >>>
> >>>
> >>> tsan.c#newcode59<
> https://codereview.appspot.com/14271043/diff/11001/gcc/tsan.c#newcode59>
> >>>>
> >>>> >
> >>>> >> > gcc/tsan.c:59: if ((flag_sanitize & SANITIZE_KERNEL_ADDRESS) ==
> >>>
> >>> 0)
> >>>>
> >>>> >> > On 2013/10/02 16:03:41, davidxl wrote:
> >>>> >> >
> >>>> >> >> Will this work when both thread sanitizer and kernel address
> >>>> >
> >>>> > sanitizer
> >>>> >>
> >>>> >> >>
> >>>> >> > are
> >>>> >> >
> >>>> >> >> specified?
> >>>> >> >>
> >>>> >> >
> >>>> >>
> >>>> >> > asan, tsan and kasan are incompatible, you can not enable two of
> >>>> >
> >>>> > them
> >>>> >>
> >>>> >> > tsan and kasan are in particular incompatible -- will the
> >>>
> >>> resulting
> >>>>
> >>>> >> > binary run in user space of kernel space?
> >>>> >> >
> >>>> >> >
> >>>> >
> >>>> >
> >>>> >
> >>>
> >>>
> >>> https://codereview.appspot.**com/14271043/%3Chttps://
> codereview.appspot.com/14271043/>
> >>>>
> >>>> >>
> >>>> >> >
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> > https://codereview.appspot.com/14271043/
> >>>
> >>>
> >>>
> >>> https://codereview.appspot.com/14271043/
>

[davidxl, 2014-03-26 19:38:14]

That depends on what compiler you plan to use this functionality. If
it is v17, then you need to port it to google/gcc-4_8 (with dependent
patches backported). Otherwise google/main is fine.

David

On Wed, Mar 26, 2014 at 12:20 PM, Alexey Preobrazhensky
<preobr@google.com> wrote:
> This patch will not fit on top of google/gcc-4_8
> (it modifies enum sanitize_code in gcc/flag-types.h, which is not present in
> google/gcc-4_8).
>
> Should I base it on google/gcc-4_9 or google/main?
>
> On Wed, Mar 26, 2014 at 11:01 PM, Xinliang David Li <davidxl@google.com>
> wrote:
>>
>> still google/gcc-4_8.
>>
>> The subject line should starts with [GOOGLE]:
>>
>> thanks,
>>
>> David
>>
>> On Wed, Mar 26, 2014 at 11:59 AM, Dmitry Vyukov <dvyukov@google.com>
>> wrote:
>> > What branch do we need to use as base now?
>> >
>> >
>> > On Wed, Mar 26, 2014 at 10:57 PM, Xinliang David Li <davidxl@google.com>
>> > wrote:
>> >> Please submit another one to gcc-patches@, cc Dmitry and me.
>> >>
>> >> thanks,
>> >>
>> >> David
>> >>
>> >> On Wed, Mar 26, 2014 at 11:55 AM,  <preobr@google.com> wrote:
>> >>> Hi,
>> >>>
>> >>> we are interested in submitting this change to crosstool.
>> >>> Should we go through another review or just rebase and submit?
>> >>>
>> >>> Where is Google v17 branch?
>> >>>
>> >>> Alexey
>> >>>
>> >>> On 2013/10/10 18:18:30, davidxl wrote:
>> >>>>
>> >>>> The change is ok for Google v17 branch for now.
>> >>>
>> >>>
>> >>>> David
>> >>>
>> >>>
>> >>>> On Thu, Oct 10, 2013 at 5:02 AM,  <mailto:dvyukov@google.com> wrote:
>> >>>> > On 2013/10/08 20:03:07, http://bjanakiraman_google.com wrote:
>> >>>> >>
>> >>>> >> Hi Dmitry,
>> >>>> >> I don't understand 'temporal implementation'. Is this meant to be
>> >>>> >
>> >>>> > stop-gap,
>> >>>> >>
>> >>>> >> and if yes, for how long?
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > Yes, this is a stop-gap.
>> >>>> > It's difficult to say for how long exactly. We want to hire a new
>> >>>> > developer for this project (which may happen next week), and then
>> >>>
>> >>> there
>> >>>>
>> >>>> > will be several potential directions: improve runtime, deployment
>> >>>
>> >>> into
>> >>>>
>> >>>> > prodkernel/ChromeOS, replace the stop-gap compiler instrumentation
>> >>>
>> >>> with
>> >>>>
>> >>>> > the final one.
>> >>>> > I would say it can be 1-6 months or so.
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> >> Its great to have this functionality, but my preference is to get
>> >>>
>> >>> it
>> >>>>
>> >>>> >> upstream. It is a big re-write, or are you more worried about the
>> >>>> >
>> >>>> > process
>> >>>> >>
>> >>>> >> of upstreaming?
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > I am more worried that it's a stop-gap solution, but at the same
>> >>>
>> >>> time we
>> >>>>
>> >>>> > want this in crosstool ASAP.
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> >> On Tue, Oct 8, 2013 at 10:42 AM, <mailto:dvyukov@google.com>
>> >>>> >> wrote:
>> >>>> >
>> >>>> >
>> >>>> >> >
>> >>>> >> >
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>
>> >>>
>> >>>
>> >>>
https://codereview.appspot.**com/14271043/diff/11001/gcc/**tsan.c%3Chttps://c...>
>> >>>>
>> >>>> >>
>> >>>> >> > File gcc/tsan.c (right):
>> >>>> >> >
>> >>>> >> > https://codereview.appspot.**com/14271043/diff/11001/gcc/**
>> >>>> >> >
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>
>> >>>
>> >>>
>> >>>
tsan.c#newcode45<https://codereview.appspot.com/14271043/diff/11001/gcc/tsan.c#newcode45>
>> >>>>
>> >>>> >>
>> >>>> >> > gcc/tsan.c:45: the instrumentation is not finalized yet and we
>> >>>
>> >>> would
>> >>>>
>> >>>> >> > like to have
>> >>>> >> > On 2013/10/02 16:03:41, davidxl wrote:
>> >>>> >> >
>> >>>> >> >> I think this this is weird. It is better not mix address
>> >>>
>> >>> sanitizer
>> >>>>
>> >>>> >> >>
>> >>>> >> > code in
>> >>>> >> >
>> >>>> >> >> tsan.c.
>> >>>> >> >>
>> >>>> >> >
>> >>>> >> > Yes, this is weird.
>> >>>> >> > Eventually kasan will use asan instrumentation pass with some
>> >>>> >
>> >>>> > minimal
>> >>>> >>
>> >>>> >> > changes.
>> >>>> >> > But for now we want to get something into crosstool, so that
>> >>>> >> > it's
>> >>>> >> > available for prodkernel and ChromeOS. Upstream gcc is nice but
>> >>>
>> >>> not
>> >>>>
>> >>>> >> > particularly critical at this point.
>> >>>> >> > Taking into account that the current code is a temporal
>> >>>> >
>> >>>> > implementation,
>> >>>> >>
>> >>>> >> > it's unclear whether it makes sense to put a lot of effort into
>> >>>
>> >>> it.
>> >>>>
>> >>>> >> >
>> >>>> >> >
>> >>>> >> > https://codereview.appspot.**com/14271043/diff/11001/gcc/**
>> >>>> >> >
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>
>> >>>
>> >>>
>> >>>
tsan.c#newcode59<https://codereview.appspot.com/14271043/diff/11001/gcc/tsan.c#newcode59>
>> >>>>
>> >>>> >
>> >>>> >> > gcc/tsan.c:59: if ((flag_sanitize & SANITIZE_KERNEL_ADDRESS) ==
>> >>>
>> >>> 0)
>> >>>>
>> >>>> >> > On 2013/10/02 16:03:41, davidxl wrote:
>> >>>> >> >
>> >>>> >> >> Will this work when both thread sanitizer and kernel address
>> >>>> >
>> >>>> > sanitizer
>> >>>> >>
>> >>>> >> >>
>> >>>> >> > are
>> >>>> >> >
>> >>>> >> >> specified?
>> >>>> >> >>
>> >>>> >> >
>> >>>> >>
>> >>>> >> > asan, tsan and kasan are incompatible, you can not enable two of
>> >>>> >
>> >>>> > them
>> >>>> >>
>> >>>> >> > tsan and kasan are in particular incompatible -- will the
>> >>>
>> >>> resulting
>> >>>>
>> >>>> >> > binary run in user space of kernel space?
>> >>>> >> >
>> >>>> >> >
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>
>> >>>
>> >>>
>> >>>
https://codereview.appspot.**com/14271043/%3Chttps://codereview.appspot.com/1...>
>> >>>>
>> >>>> >>
>> >>>> >> >
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > https://codereview.appspot.com/14271043/
>> >>>
>> >>>
>> >>>
>> >>> https://codereview.appspot.com/14271043/
>
>