Re: [RFC PATCH] Merge libsanitizer from upstream

[Christophe Lyon]

On 16 November 2017 at 13:25, Maxim Ostapenko  wrote:
> Hi Christophe,
>
> On 13/11/17 15:47, Christophe Lyon wrote:
>>
>> On 30 October 2017 at 16:21, Maxim Ostapenko 
>> wrote:
>>>
>>> On 30/10/17 17:08, Christophe Lyon wrote:

 On 30/10/2017 11:12, Maxim Ostapenko wrote:
>
> Hi,
>
> sorry for the late response.
>
> On 20/10/17 13:45, Christophe Lyon wrote:
>>
>> Hi,
>>
>> On 19 October 2017 at 13:17, Jakub Jelinek  wrote:
>>>
>>> On Thu, Oct 19, 2017 at 02:07:24PM +0300, Maxim Ostapenko wrote:
>
> Is the patch (the merge + this incremental) ok for trunk?

 I think the patch is OK, just wondering about two things:
>>>
>>> Richi just approved the patch on IRC, so I'll commit, then we can
>>> deal
>>> with
>>> follow-ups.
>>>
>> Does anyone else run these tests on arm?
>> Since you applied this patch, I'm seeing lots of new errors and
>> timeouts.
>> I have been ignoring regression reports for *san because of
>> yyrandomness
>> in the results, but the timeouts are a  major inconvenience in testing
>> because it increases latency a lot in getting results, or worse I get
>> no
>> result at all because the validation job is killed before completion.
>>
>> Looking at some intermediate logs, I have noticed:
>> ==24797==AddressSanitizer CHECK failed:
>> /libsanitizer/asan/asan_poisoning.cc:34
>> "((AddrIsAlignedByGranularity(addr))) != (0)" (0x0, 0x0)
>>   #0 0x408d7d65 in AsanCheckFailed
>> /libsanitizer/asan/asan_rtl.cc:67
>>   #1 0x408ecd5d in __sanitizer::CheckFailed(char const*, int, char
>> const*, unsigned long long, unsigned long long)
>> /libsanitizer/sanitizer_common/sanitizer_termination.cc:77
>>   #2 0x408d22d5 in __asan::PoisonShadow(unsigned long, unsigned
>> long, unsigned char) /libsanitizer/asan/asan_poisoning.cc:34
>>   #3 0x4085409b in __asan_register_globals
>> /libsanitizer/asan/asan_globals.cc:368
>>   #4 0x109eb in _GLOBAL__sub_I_00099_1_ten
>>
>>
>> (/aci-gcc-fsf/builds/gcc-fsf-gccsrc-thumb/obj-arm-none-linux-gnueabi/gcc3/gcc/testsuite/gcc/alloca_big_alignment.exe+0x109eb)
>>
>> in MANY (193 in gcc) tests.
>>
>> and many others (152 in gcc) just time out individually (eg
>> c-c++-common/asan/alloca_instruments_all_paddings.c) with no error in
>> the logs besides Dejagnu's
>> WARNING: program timed out.
>>
>>
>> Since I'm using an apparently unusual setup, maybe I have to update it
>> to cope with the new version,
>> so I'd like to know if others are seeing the same problems on arm?
>>
>> I'm using qemu -R 0 to execute the test programs, encapsulated by
>> proot (similar to chroot, but does not require root privileges).
>>
>> Am I missing something obvious?
>
>
> I've caught the same error on my Arndale board. The issue seems to be
> quite obvious: after merge, ASan requires globals array to be aligned
> by
> shadow granularity.


 Thanks for confirming. I've spent a lot of time investigating the
 timeout
 issues, that led to zombie processes and servers needing reboot. I've
 finally identified that going back to qemu-2.7 avoid the timeout issues
 (I've reported a qemu bug).

> This trivial patch seems to fix the issue. Could you check it on your
> setup?
>
 I was just about to finally start looking at this sanity check problem,
 so
 thank you very much for sharing your patch.
 I manually tested it on the subset of my configs and it solves the
 assertion failure, thanks!
 However, I can notice many regressions compared to before the merge:
 c-c++-common/asan/alloca_instruments_all_paddings.c
 c-c++-common/asan/alloca_loop_unpoisoning.c
 c-c++-common/asan/alloca_safe_access.c
 c-c++-common/asan/asan-interface-1.c
 c-c++-common/asan/halt_on_error-1.c
 c-c++-common/asan/pr59063-1.c
 c-c++-common/asan/pr59063-2.c
 c-c++-common/asan/pr63316.c
 c-c++-common/asan/pr63888.c
 c-c++-common/asan/pr70712.c
 c-c++-common/asan/pr71480.c
 c-c++-common/asan/pr79944.c
 c-c++-common/asan/pr80308.c
 c-c++-common/asan/swapcontext-test-1.c
 gcc.dg/asan/nosanitize-and-inline.c
 gcc.dg/asan/pr79196.c
 gcc.dg/asan/pr80166.c
 gcc.dg/asan/pr81186.c
 gcc.dg/asan/use-after-scope-11.c
 gcc.dg/asan/use-after-scope-4.c
 gcc.dg/asan/use-after-scope-6.c
 gcc.dg/asan/use-after-scope-7.c
 gcc.dg/asan/use-after-scope-goto-1.c
 gcc.dg/asan/use-after-scope-goto-2.c
 gcc.dg/asan/use-after-scope-switch-1.c
 gcc.dg/asan/use-after-scope-switch-2.c
 gcc.dg/asan/use-after-scope-switch-3.c
 gcc.dg/asan/use-after-scope-switch-4.c

 out of which only
 c-c++-common/asan/swapcontext-test-1.c
 c-c++-common/asan/halt_on_e

Re: [RFC PATCH] Merge libsanitizer from upstream

[Maxim Ostapenko]

Hi Christophe,

On 13/11/17 15:47, Christophe Lyon wrote:

On 30 October 2017 at 16:21, Maxim Ostapenko  wrote:

On 30/10/17 17:08, Christophe Lyon wrote:

On 30/10/2017 11:12, Maxim Ostapenko wrote:

Hi,

sorry for the late response.

On 20/10/17 13:45, Christophe Lyon wrote:

Hi,

On 19 October 2017 at 13:17, Jakub Jelinek  wrote:

On Thu, Oct 19, 2017 at 02:07:24PM +0300, Maxim Ostapenko wrote:

Is the patch (the merge + this incremental) ok for trunk?

I think the patch is OK, just wondering about two things:

Richi just approved the patch on IRC, so I'll commit, then we can deal
with
follow-ups.


Does anyone else run these tests on arm?
Since you applied this patch, I'm seeing lots of new errors and
timeouts.
I have been ignoring regression reports for *san because of yyrandomness
in the results, but the timeouts are a  major inconvenience in testing
because it increases latency a lot in getting results, or worse I get no
result at all because the validation job is killed before completion.

Looking at some intermediate logs, I have noticed:
==24797==AddressSanitizer CHECK failed:
/libsanitizer/asan/asan_poisoning.cc:34
"((AddrIsAlignedByGranularity(addr))) != (0)" (0x0, 0x0)
  #0 0x408d7d65 in AsanCheckFailed /libsanitizer/asan/asan_rtl.cc:67
  #1 0x408ecd5d in __sanitizer::CheckFailed(char const*, int, char
const*, unsigned long long, unsigned long long)
/libsanitizer/sanitizer_common/sanitizer_termination.cc:77
  #2 0x408d22d5 in __asan::PoisonShadow(unsigned long, unsigned
long, unsigned char) /libsanitizer/asan/asan_poisoning.cc:34
  #3 0x4085409b in __asan_register_globals
/libsanitizer/asan/asan_globals.cc:368
  #4 0x109eb in _GLOBAL__sub_I_00099_1_ten

(/aci-gcc-fsf/builds/gcc-fsf-gccsrc-thumb/obj-arm-none-linux-gnueabi/gcc3/gcc/testsuite/gcc/alloca_big_alignment.exe+0x109eb)

in MANY (193 in gcc) tests.

and many others (152 in gcc) just time out individually (eg
c-c++-common/asan/alloca_instruments_all_paddings.c) with no error in
the logs besides Dejagnu's
WARNING: program timed out.


Since I'm using an apparently unusual setup, maybe I have to update it
to cope with the new version,
so I'd like to know if others are seeing the same problems on arm?

I'm using qemu -R 0 to execute the test programs, encapsulated by
proot (similar to chroot, but does not require root privileges).

Am I missing something obvious?


I've caught the same error on my Arndale board. The issue seems to be
quite obvious: after merge, ASan requires globals array to be aligned by
shadow granularity.


Thanks for confirming. I've spent a lot of time investigating the timeout
issues, that led to zombie processes and servers needing reboot. I've
finally identified that going back to qemu-2.7 avoid the timeout issues
(I've reported a qemu bug).


This trivial patch seems to fix the issue. Could you check it on your
setup?


I was just about to finally start looking at this sanity check problem, so
thank you very much for sharing your patch.
I manually tested it on the subset of my configs and it solves the
assertion failure, thanks!
However, I can notice many regressions compared to before the merge:
c-c++-common/asan/alloca_instruments_all_paddings.c
c-c++-common/asan/alloca_loop_unpoisoning.c
c-c++-common/asan/alloca_safe_access.c
c-c++-common/asan/asan-interface-1.c
c-c++-common/asan/halt_on_error-1.c
c-c++-common/asan/pr59063-1.c
c-c++-common/asan/pr59063-2.c
c-c++-common/asan/pr63316.c
c-c++-common/asan/pr63888.c
c-c++-common/asan/pr70712.c
c-c++-common/asan/pr71480.c
c-c++-common/asan/pr79944.c
c-c++-common/asan/pr80308.c
c-c++-common/asan/swapcontext-test-1.c
gcc.dg/asan/nosanitize-and-inline.c
gcc.dg/asan/pr79196.c
gcc.dg/asan/pr80166.c
gcc.dg/asan/pr81186.c
gcc.dg/asan/use-after-scope-11.c
gcc.dg/asan/use-after-scope-4.c
gcc.dg/asan/use-after-scope-6.c
gcc.dg/asan/use-after-scope-7.c
gcc.dg/asan/use-after-scope-goto-1.c
gcc.dg/asan/use-after-scope-goto-2.c
gcc.dg/asan/use-after-scope-switch-1.c
gcc.dg/asan/use-after-scope-switch-2.c
gcc.dg/asan/use-after-scope-switch-3.c
gcc.dg/asan/use-after-scope-switch-4.c

out of which only
c-c++-common/asan/swapcontext-test-1.c
c-c++-common/asan/halt_on_error-1.c
print something in gcc.log

Do they pass for you?


Ah, I see. The problem is that after this merge LSan was enabled for ARM.
LSan sets atexit handler that calls internal_clone function that's not
supported in QEMU.
That's why these tests pass on board, but fail under QEMU.
Could you try set ASAN_OPTIONS=detect_leaks=0 in your environment?


Hi,

I have a followup on this issue, after investigating a bit more.

I filed a bug report against QEMU, and indeed it seems that it rejects
clone() as called by the sanitizers on purpose, because it cannot support
CLONE_UNTRACED.

That being said, I was wondering why the same tests worked "better"
with qemu-aarch64 (as opposed to qemu-arm). And I noticed that on aarch64,
we have sanitizer_common/sanitizer_syscall_linux_aarch64.inc where
internal_iserror

Re: [RFC PATCH] Merge libsanitizer from upstream

[Jakub Jelinek]

On Tue, Nov 14, 2017 at 06:40:32PM +0300, Maxim Ostapenko wrote:
> > But on the upstream sanitizer repo,
> > sanitizer_common/sanitizer_syscall_linux_arm.inc was added on Nov 8th,
> > and also checks for retval >= -4095, hence handling the clone() error
> > gracefully. So... can we merge again our sanitizer sources to at least
> > http://llvm.org/viewvc/llvm-project?view=revision&revision=317640 ?
> 
> I think we could just cherry-pick this commit from upstream. I can handle
> this if it's not too late given the fact that GCC is on stage 3 now.

stage3 starts only during the weekend.

Jakub

Re: [RFC PATCH] Merge libsanitizer from upstream

[Maxim Ostapenko]

Hi,

On 13/11/17 15:47, Christophe Lyon wrote:

On 30 October 2017 at 16:21, Maxim Ostapenko  wrote:

On 30/10/17 17:08, Christophe Lyon wrote:

On 30/10/2017 11:12, Maxim Ostapenko wrote:

Hi,

sorry for the late response.

On 20/10/17 13:45, Christophe Lyon wrote:

Hi,

On 19 October 2017 at 13:17, Jakub Jelinek  wrote:

On Thu, Oct 19, 2017 at 02:07:24PM +0300, Maxim Ostapenko wrote:

Is the patch (the merge + this incremental) ok for trunk?

I think the patch is OK, just wondering about two things:

Richi just approved the patch on IRC, so I'll commit, then we can deal
with
follow-ups.


Does anyone else run these tests on arm?
Since you applied this patch, I'm seeing lots of new errors and
timeouts.
I have been ignoring regression reports for *san because of yyrandomness
in the results, but the timeouts are a  major inconvenience in testing
because it increases latency a lot in getting results, or worse I get no
result at all because the validation job is killed before completion.

Looking at some intermediate logs, I have noticed:
==24797==AddressSanitizer CHECK failed:
/libsanitizer/asan/asan_poisoning.cc:34
"((AddrIsAlignedByGranularity(addr))) != (0)" (0x0, 0x0)
  #0 0x408d7d65 in AsanCheckFailed /libsanitizer/asan/asan_rtl.cc:67
  #1 0x408ecd5d in __sanitizer::CheckFailed(char const*, int, char
const*, unsigned long long, unsigned long long)
/libsanitizer/sanitizer_common/sanitizer_termination.cc:77
  #2 0x408d22d5 in __asan::PoisonShadow(unsigned long, unsigned
long, unsigned char) /libsanitizer/asan/asan_poisoning.cc:34
  #3 0x4085409b in __asan_register_globals
/libsanitizer/asan/asan_globals.cc:368
  #4 0x109eb in _GLOBAL__sub_I_00099_1_ten

(/aci-gcc-fsf/builds/gcc-fsf-gccsrc-thumb/obj-arm-none-linux-gnueabi/gcc3/gcc/testsuite/gcc/alloca_big_alignment.exe+0x109eb)

in MANY (193 in gcc) tests.

and many others (152 in gcc) just time out individually (eg
c-c++-common/asan/alloca_instruments_all_paddings.c) with no error in
the logs besides Dejagnu's
WARNING: program timed out.


Since I'm using an apparently unusual setup, maybe I have to update it
to cope with the new version,
so I'd like to know if others are seeing the same problems on arm?

I'm using qemu -R 0 to execute the test programs, encapsulated by
proot (similar to chroot, but does not require root privileges).

Am I missing something obvious?


I've caught the same error on my Arndale board. The issue seems to be
quite obvious: after merge, ASan requires globals array to be aligned by
shadow granularity.


Thanks for confirming. I've spent a lot of time investigating the timeout
issues, that led to zombie processes and servers needing reboot. I've
finally identified that going back to qemu-2.7 avoid the timeout issues
(I've reported a qemu bug).


This trivial patch seems to fix the issue. Could you check it on your
setup?


I was just about to finally start looking at this sanity check problem, so
thank you very much for sharing your patch.
I manually tested it on the subset of my configs and it solves the
assertion failure, thanks!
However, I can notice many regressions compared to before the merge:
c-c++-common/asan/alloca_instruments_all_paddings.c
c-c++-common/asan/alloca_loop_unpoisoning.c
c-c++-common/asan/alloca_safe_access.c
c-c++-common/asan/asan-interface-1.c
c-c++-common/asan/halt_on_error-1.c
c-c++-common/asan/pr59063-1.c
c-c++-common/asan/pr59063-2.c
c-c++-common/asan/pr63316.c
c-c++-common/asan/pr63888.c
c-c++-common/asan/pr70712.c
c-c++-common/asan/pr71480.c
c-c++-common/asan/pr79944.c
c-c++-common/asan/pr80308.c
c-c++-common/asan/swapcontext-test-1.c
gcc.dg/asan/nosanitize-and-inline.c
gcc.dg/asan/pr79196.c
gcc.dg/asan/pr80166.c
gcc.dg/asan/pr81186.c
gcc.dg/asan/use-after-scope-11.c
gcc.dg/asan/use-after-scope-4.c
gcc.dg/asan/use-after-scope-6.c
gcc.dg/asan/use-after-scope-7.c
gcc.dg/asan/use-after-scope-goto-1.c
gcc.dg/asan/use-after-scope-goto-2.c
gcc.dg/asan/use-after-scope-switch-1.c
gcc.dg/asan/use-after-scope-switch-2.c
gcc.dg/asan/use-after-scope-switch-3.c
gcc.dg/asan/use-after-scope-switch-4.c

out of which only
c-c++-common/asan/swapcontext-test-1.c
c-c++-common/asan/halt_on_error-1.c
print something in gcc.log

Do they pass for you?


Ah, I see. The problem is that after this merge LSan was enabled for ARM.
LSan sets atexit handler that calls internal_clone function that's not
supported in QEMU.
That's why these tests pass on board, but fail under QEMU.
Could you try set ASAN_OPTIONS=detect_leaks=0 in your environment?


Hi,

I have a followup on this issue, after investigating a bit more.

I filed a bug report against QEMU, and indeed it seems that it rejects
clone() as called by the sanitizers on purpose, because it cannot support
CLONE_UNTRACED.

That being said, I was wondering why the same tests worked "better"
with qemu-aarch64 (as opposed to qemu-arm). And I noticed that on aarch64,
we have sanitizer_common/sanitizer_syscall_linux_aarch64.inc where
internal_iserror returns tr

Re: [RFC PATCH] Merge libsanitizer from upstream

[Christophe Lyon]

On 30 October 2017 at 16:21, Maxim Ostapenko  wrote:
> On 30/10/17 17:08, Christophe Lyon wrote:
>>
>> On 30/10/2017 11:12, Maxim Ostapenko wrote:
>>>
>>> Hi,
>>>
>>> sorry for the late response.
>>>
>>> On 20/10/17 13:45, Christophe Lyon wrote:

 Hi,

 On 19 October 2017 at 13:17, Jakub Jelinek  wrote:
>
> On Thu, Oct 19, 2017 at 02:07:24PM +0300, Maxim Ostapenko wrote:
>>>
>>> Is the patch (the merge + this incremental) ok for trunk?
>>
>> I think the patch is OK, just wondering about two things:
>
> Richi just approved the patch on IRC, so I'll commit, then we can deal
> with
> follow-ups.
>
 Does anyone else run these tests on arm?
 Since you applied this patch, I'm seeing lots of new errors and
 timeouts.
 I have been ignoring regression reports for *san because of yyrandomness
 in the results, but the timeouts are a  major inconvenience in testing
 because it increases latency a lot in getting results, or worse I get no
 result at all because the validation job is killed before completion.

 Looking at some intermediate logs, I have noticed:
 ==24797==AddressSanitizer CHECK failed:
 /libsanitizer/asan/asan_poisoning.cc:34
 "((AddrIsAlignedByGranularity(addr))) != (0)" (0x0, 0x0)
  #0 0x408d7d65 in AsanCheckFailed /libsanitizer/asan/asan_rtl.cc:67
  #1 0x408ecd5d in __sanitizer::CheckFailed(char const*, int, char
 const*, unsigned long long, unsigned long long)
 /libsanitizer/sanitizer_common/sanitizer_termination.cc:77
  #2 0x408d22d5 in __asan::PoisonShadow(unsigned long, unsigned
 long, unsigned char) /libsanitizer/asan/asan_poisoning.cc:34
  #3 0x4085409b in __asan_register_globals
 /libsanitizer/asan/asan_globals.cc:368
  #4 0x109eb in _GLOBAL__sub_I_00099_1_ten

 (/aci-gcc-fsf/builds/gcc-fsf-gccsrc-thumb/obj-arm-none-linux-gnueabi/gcc3/gcc/testsuite/gcc/alloca_big_alignment.exe+0x109eb)

 in MANY (193 in gcc) tests.

 and many others (152 in gcc) just time out individually (eg
 c-c++-common/asan/alloca_instruments_all_paddings.c) with no error in
 the logs besides Dejagnu's
 WARNING: program timed out.


 Since I'm using an apparently unusual setup, maybe I have to update it
 to cope with the new version,
 so I'd like to know if others are seeing the same problems on arm?

 I'm using qemu -R 0 to execute the test programs, encapsulated by
 proot (similar to chroot, but does not require root privileges).

 Am I missing something obvious?
>>>
>>>
>>> I've caught the same error on my Arndale board. The issue seems to be
>>> quite obvious: after merge, ASan requires globals array to be aligned by
>>> shadow granularity.
>>
>>
>> Thanks for confirming. I've spent a lot of time investigating the timeout
>> issues, that led to zombie processes and servers needing reboot. I've
>> finally identified that going back to qemu-2.7 avoid the timeout issues
>> (I've reported a qemu bug).
>>
>>> This trivial patch seems to fix the issue. Could you check it on your
>>> setup?
>>>
>> I was just about to finally start looking at this sanity check problem, so
>> thank you very much for sharing your patch.
>> I manually tested it on the subset of my configs and it solves the
>> assertion failure, thanks!
>> However, I can notice many regressions compared to before the merge:
>> c-c++-common/asan/alloca_instruments_all_paddings.c
>> c-c++-common/asan/alloca_loop_unpoisoning.c
>> c-c++-common/asan/alloca_safe_access.c
>> c-c++-common/asan/asan-interface-1.c
>> c-c++-common/asan/halt_on_error-1.c
>> c-c++-common/asan/pr59063-1.c
>> c-c++-common/asan/pr59063-2.c
>> c-c++-common/asan/pr63316.c
>> c-c++-common/asan/pr63888.c
>> c-c++-common/asan/pr70712.c
>> c-c++-common/asan/pr71480.c
>> c-c++-common/asan/pr79944.c
>> c-c++-common/asan/pr80308.c
>> c-c++-common/asan/swapcontext-test-1.c
>> gcc.dg/asan/nosanitize-and-inline.c
>> gcc.dg/asan/pr79196.c
>> gcc.dg/asan/pr80166.c
>> gcc.dg/asan/pr81186.c
>> gcc.dg/asan/use-after-scope-11.c
>> gcc.dg/asan/use-after-scope-4.c
>> gcc.dg/asan/use-after-scope-6.c
>> gcc.dg/asan/use-after-scope-7.c
>> gcc.dg/asan/use-after-scope-goto-1.c
>> gcc.dg/asan/use-after-scope-goto-2.c
>> gcc.dg/asan/use-after-scope-switch-1.c
>> gcc.dg/asan/use-after-scope-switch-2.c
>> gcc.dg/asan/use-after-scope-switch-3.c
>> gcc.dg/asan/use-after-scope-switch-4.c
>>
>> out of which only
>> c-c++-common/asan/swapcontext-test-1.c
>> c-c++-common/asan/halt_on_error-1.c
>> print something in gcc.log
>>
>> Do they pass for you?
>
>
> Ah, I see. The problem is that after this merge LSan was enabled for ARM.
> LSan sets atexit handler that calls internal_clone function that's not
> supported in QEMU.
> That's why these tests pass on board, but fail under QEMU.
> Could you try set ASAN_OPTIONS=detect_leaks=0 in your environment?
>

Hi,

I have a followup on this issue, after i

Re: [RFC PATCH] Merge libsanitizer from upstream

[Christophe Lyon]

On 30/10/2017 16:54, Maxim Ostapenko wrote:

On 30/10/17 18:46, Christophe Lyon wrote:

On 30/10/2017 16:21, Maxim Ostapenko wrote:

On 30/10/17 17:08, Christophe Lyon wrote:

On 30/10/2017 11:12, Maxim Ostapenko wrote:

Hi,

sorry for the late response.

On 20/10/17 13:45, Christophe Lyon wrote:

Hi,

On 19 October 2017 at 13:17, Jakub Jelinek  wrote:

On Thu, Oct 19, 2017 at 02:07:24PM +0300, Maxim Ostapenko wrote:

Is the patch (the merge + this incremental) ok for trunk?

I think the patch is OK, just wondering about two things:

Richi just approved the patch on IRC, so I'll commit, then we can deal with
follow-ups.


Does anyone else run these tests on arm?
Since you applied this patch, I'm seeing lots of new errors and timeouts.
I have been ignoring regression reports for *san because of yyrandomness
in the results, but the timeouts are a  major inconvenience in testing
because it increases latency a lot in getting results, or worse I get no
result at all because the validation job is killed before completion.

Looking at some intermediate logs, I have noticed:
==24797==AddressSanitizer CHECK failed:
/libsanitizer/asan/asan_poisoning.cc:34
"((AddrIsAlignedByGranularity(addr))) != (0)" (0x0, 0x0)
 #0 0x408d7d65 in AsanCheckFailed /libsanitizer/asan/asan_rtl.cc:67
 #1 0x408ecd5d in __sanitizer::CheckFailed(char const*, int, char
const*, unsigned long long, unsigned long long)
/libsanitizer/sanitizer_common/sanitizer_termination.cc:77
 #2 0x408d22d5 in __asan::PoisonShadow(unsigned long, unsigned
long, unsigned char) /libsanitizer/asan/asan_poisoning.cc:34
 #3 0x4085409b in __asan_register_globals
/libsanitizer/asan/asan_globals.cc:368
 #4 0x109eb in _GLOBAL__sub_I_00099_1_ten
(/aci-gcc-fsf/builds/gcc-fsf-gccsrc-thumb/obj-arm-none-linux-gnueabi/gcc3/gcc/testsuite/gcc/alloca_big_alignment.exe+0x109eb)

in MANY (193 in gcc) tests.

and many others (152 in gcc) just time out individually (eg
c-c++-common/asan/alloca_instruments_all_paddings.c) with no error in
the logs besides Dejagnu's
WARNING: program timed out.


Since I'm using an apparently unusual setup, maybe I have to update it
to cope with the new version,
so I'd like to know if others are seeing the same problems on arm?

I'm using qemu -R 0 to execute the test programs, encapsulated by
proot (similar to chroot, but does not require root privileges).

Am I missing something obvious?


I've caught the same error on my Arndale board. The issue seems to be quite 
obvious: after merge, ASan requires globals array to be aligned by shadow 
granularity.


Thanks for confirming. I've spent a lot of time investigating the timeout 
issues, that led to zombie processes and servers needing reboot. I've finally 
identified that going back to qemu-2.7 avoid the timeout issues (I've reported 
a qemu bug).


This trivial patch seems to fix the issue. Could you check it on your setup?


I was just about to finally start looking at this sanity check problem, so 
thank you very much for sharing your patch.
I manually tested it on the subset of my configs and it solves the assertion 
failure, thanks!
However, I can notice many regressions compared to before the merge:
c-c++-common/asan/alloca_instruments_all_paddings.c
c-c++-common/asan/alloca_loop_unpoisoning.c
c-c++-common/asan/alloca_safe_access.c
c-c++-common/asan/asan-interface-1.c
c-c++-common/asan/halt_on_error-1.c
c-c++-common/asan/pr59063-1.c
c-c++-common/asan/pr59063-2.c
c-c++-common/asan/pr63316.c
c-c++-common/asan/pr63888.c
c-c++-common/asan/pr70712.c
c-c++-common/asan/pr71480.c
c-c++-common/asan/pr79944.c
c-c++-common/asan/pr80308.c
c-c++-common/asan/swapcontext-test-1.c
gcc.dg/asan/nosanitize-and-inline.c
gcc.dg/asan/pr79196.c
gcc.dg/asan/pr80166.c
gcc.dg/asan/pr81186.c
gcc.dg/asan/use-after-scope-11.c
gcc.dg/asan/use-after-scope-4.c
gcc.dg/asan/use-after-scope-6.c
gcc.dg/asan/use-after-scope-7.c
gcc.dg/asan/use-after-scope-goto-1.c
gcc.dg/asan/use-after-scope-goto-2.c
gcc.dg/asan/use-after-scope-switch-1.c
gcc.dg/asan/use-after-scope-switch-2.c
gcc.dg/asan/use-after-scope-switch-3.c
gcc.dg/asan/use-after-scope-switch-4.c

out of which only
c-c++-common/asan/swapcontext-test-1.c
c-c++-common/asan/halt_on_error-1.c
print something in gcc.log

Do they pass for you?


Ah, I see. The problem is that after this merge LSan was enabled for ARM. LSan 
sets atexit handler that calls internal_clone function that's not supported in 
QEMU.
That's why these tests pass on board, but fail under QEMU.
Could you try set ASAN_OPTIONS=detect_leaks=0 in your environment?



Ha, thanks it works!

The remaining failure is on c-c++-common/asan/halt_on_error-1.c, which seems to 
dump the expected messages, but exits with return code=4.


Same here, halt_on_error-1.c just overwrites ASAN_OPTIONS via 
"halt_on_error=false" thus enabling LSan back.
Something like this (attached) should work.



Indeed, thanks a lot!

It looks like I'm going to have to apply local patches such as this one if I 
want to contin

Re: [RFC PATCH] Merge libsanitizer from upstream

[Maxim Ostapenko]

On 30/10/17 18:46, Christophe Lyon wrote:

On 30/10/2017 16:21, Maxim Ostapenko wrote:

On 30/10/17 17:08, Christophe Lyon wrote:

On 30/10/2017 11:12, Maxim Ostapenko wrote:

Hi,

sorry for the late response.

On 20/10/17 13:45, Christophe Lyon wrote:

Hi,

On 19 October 2017 at 13:17, Jakub Jelinek  wrote:

On Thu, Oct 19, 2017 at 02:07:24PM +0300, Maxim Ostapenko wrote:

Is the patch (the merge + this incremental) ok for trunk?

I think the patch is OK, just wondering about two things:
Richi just approved the patch on IRC, so I'll commit, then we can 
deal with

follow-ups.


Does anyone else run these tests on arm?
Since you applied this patch, I'm seeing lots of new errors and 
timeouts.
I have been ignoring regression reports for *san because of 
yyrandomness
in the results, but the timeouts are a  major inconvenience in 
testing
because it increases latency a lot in getting results, or worse I 
get no

result at all because the validation job is killed before completion.

Looking at some intermediate logs, I have noticed:
==24797==AddressSanitizer CHECK failed:
/libsanitizer/asan/asan_poisoning.cc:34
"((AddrIsAlignedByGranularity(addr))) != (0)" (0x0, 0x0)
 #0 0x408d7d65 in AsanCheckFailed 
/libsanitizer/asan/asan_rtl.cc:67

 #1 0x408ecd5d in __sanitizer::CheckFailed(char const*, int, char
const*, unsigned long long, unsigned long long)
/libsanitizer/sanitizer_common/sanitizer_termination.cc:77
 #2 0x408d22d5 in __asan::PoisonShadow(unsigned long, unsigned
long, unsigned char) /libsanitizer/asan/asan_poisoning.cc:34
 #3 0x4085409b in __asan_register_globals
/libsanitizer/asan/asan_globals.cc:368
 #4 0x109eb in _GLOBAL__sub_I_00099_1_ten
(/aci-gcc-fsf/builds/gcc-fsf-gccsrc-thumb/obj-arm-none-linux-gnueabi/gcc3/gcc/testsuite/gcc/alloca_big_alignment.exe+0x109eb) 



in MANY (193 in gcc) tests.

and many others (152 in gcc) just time out individually (eg
c-c++-common/asan/alloca_instruments_all_paddings.c) with no error in
the logs besides Dejagnu's
WARNING: program timed out.


Since I'm using an apparently unusual setup, maybe I have to 
update it

to cope with the new version,
so I'd like to know if others are seeing the same problems on arm?

I'm using qemu -R 0 to execute the test programs, encapsulated by
proot (similar to chroot, but does not require root privileges).

Am I missing something obvious?


I've caught the same error on my Arndale board. The issue seems to 
be quite obvious: after merge, ASan requires globals array to be 
aligned by shadow granularity.


Thanks for confirming. I've spent a lot of time investigating the 
timeout issues, that led to zombie processes and servers needing 
reboot. I've finally identified that going back to qemu-2.7 avoid 
the timeout issues (I've reported a qemu bug).


This trivial patch seems to fix the issue. Could you check it on 
your setup?


I was just about to finally start looking at this sanity check 
problem, so thank you very much for sharing your patch.
I manually tested it on the subset of my configs and it solves the 
assertion failure, thanks!

However, I can notice many regressions compared to before the merge:
c-c++-common/asan/alloca_instruments_all_paddings.c
c-c++-common/asan/alloca_loop_unpoisoning.c
c-c++-common/asan/alloca_safe_access.c
c-c++-common/asan/asan-interface-1.c
c-c++-common/asan/halt_on_error-1.c
c-c++-common/asan/pr59063-1.c
c-c++-common/asan/pr59063-2.c
c-c++-common/asan/pr63316.c
c-c++-common/asan/pr63888.c
c-c++-common/asan/pr70712.c
c-c++-common/asan/pr71480.c
c-c++-common/asan/pr79944.c
c-c++-common/asan/pr80308.c
c-c++-common/asan/swapcontext-test-1.c
gcc.dg/asan/nosanitize-and-inline.c
gcc.dg/asan/pr79196.c
gcc.dg/asan/pr80166.c
gcc.dg/asan/pr81186.c
gcc.dg/asan/use-after-scope-11.c
gcc.dg/asan/use-after-scope-4.c
gcc.dg/asan/use-after-scope-6.c
gcc.dg/asan/use-after-scope-7.c
gcc.dg/asan/use-after-scope-goto-1.c
gcc.dg/asan/use-after-scope-goto-2.c
gcc.dg/asan/use-after-scope-switch-1.c
gcc.dg/asan/use-after-scope-switch-2.c
gcc.dg/asan/use-after-scope-switch-3.c
gcc.dg/asan/use-after-scope-switch-4.c

out of which only
c-c++-common/asan/swapcontext-test-1.c
c-c++-common/asan/halt_on_error-1.c
print something in gcc.log

Do they pass for you?


Ah, I see. The problem is that after this merge LSan was enabled for 
ARM. LSan sets atexit handler that calls internal_clone function 
that's not supported in QEMU.

That's why these tests pass on board, but fail under QEMU.
Could you try set ASAN_OPTIONS=detect_leaks=0 in your environment?



Ha, thanks it works!

The remaining failure is on c-c++-common/asan/halt_on_error-1.c, which 
seems to dump the expected messages, but exits with return code=4.


Same here, halt_on_error-1.c just overwrites ASAN_OPTIONS via 
"halt_on_error=false" thus enabling LSan back.

Something like this (attached) should work.

-Maxim



Any idea ?

Thanks,

Christophe


-Maxim



Thanks,

Christophe


Thanks,
-Maxim



Thanks,

Christophe


1) We have a bunch of GCC loc

Re: [RFC PATCH] Merge libsanitizer from upstream

[Christophe Lyon]

On 30/10/2017 16:21, Maxim Ostapenko wrote:

On 30/10/17 17:08, Christophe Lyon wrote:

On 30/10/2017 11:12, Maxim Ostapenko wrote:

Hi,

sorry for the late response.

On 20/10/17 13:45, Christophe Lyon wrote:

Hi,

On 19 October 2017 at 13:17, Jakub Jelinek  wrote:

On Thu, Oct 19, 2017 at 02:07:24PM +0300, Maxim Ostapenko wrote:

Is the patch (the merge + this incremental) ok for trunk?

I think the patch is OK, just wondering about two things:

Richi just approved the patch on IRC, so I'll commit, then we can deal with
follow-ups.


Does anyone else run these tests on arm?
Since you applied this patch, I'm seeing lots of new errors and timeouts.
I have been ignoring regression reports for *san because of yyrandomness
in the results, but the timeouts are a  major inconvenience in testing
because it increases latency a lot in getting results, or worse I get no
result at all because the validation job is killed before completion.

Looking at some intermediate logs, I have noticed:
==24797==AddressSanitizer CHECK failed:
/libsanitizer/asan/asan_poisoning.cc:34
"((AddrIsAlignedByGranularity(addr))) != (0)" (0x0, 0x0)
 #0 0x408d7d65 in AsanCheckFailed /libsanitizer/asan/asan_rtl.cc:67
 #1 0x408ecd5d in __sanitizer::CheckFailed(char const*, int, char
const*, unsigned long long, unsigned long long)
/libsanitizer/sanitizer_common/sanitizer_termination.cc:77
 #2 0x408d22d5 in __asan::PoisonShadow(unsigned long, unsigned
long, unsigned char) /libsanitizer/asan/asan_poisoning.cc:34
 #3 0x4085409b in __asan_register_globals
/libsanitizer/asan/asan_globals.cc:368
 #4 0x109eb in _GLOBAL__sub_I_00099_1_ten
(/aci-gcc-fsf/builds/gcc-fsf-gccsrc-thumb/obj-arm-none-linux-gnueabi/gcc3/gcc/testsuite/gcc/alloca_big_alignment.exe+0x109eb)

in MANY (193 in gcc) tests.

and many others (152 in gcc) just time out individually (eg
c-c++-common/asan/alloca_instruments_all_paddings.c) with no error in
the logs besides Dejagnu's
WARNING: program timed out.


Since I'm using an apparently unusual setup, maybe I have to update it
to cope with the new version,
so I'd like to know if others are seeing the same problems on arm?

I'm using qemu -R 0 to execute the test programs, encapsulated by
proot (similar to chroot, but does not require root privileges).

Am I missing something obvious?


I've caught the same error on my Arndale board. The issue seems to be quite 
obvious: after merge, ASan requires globals array to be aligned by shadow 
granularity.


Thanks for confirming. I've spent a lot of time investigating the timeout 
issues, that led to zombie processes and servers needing reboot. I've finally 
identified that going back to qemu-2.7 avoid the timeout issues (I've reported 
a qemu bug).


This trivial patch seems to fix the issue. Could you check it on your setup?


I was just about to finally start looking at this sanity check problem, so 
thank you very much for sharing your patch.
I manually tested it on the subset of my configs and it solves the assertion 
failure, thanks!
However, I can notice many regressions compared to before the merge:
c-c++-common/asan/alloca_instruments_all_paddings.c
c-c++-common/asan/alloca_loop_unpoisoning.c
c-c++-common/asan/alloca_safe_access.c
c-c++-common/asan/asan-interface-1.c
c-c++-common/asan/halt_on_error-1.c
c-c++-common/asan/pr59063-1.c
c-c++-common/asan/pr59063-2.c
c-c++-common/asan/pr63316.c
c-c++-common/asan/pr63888.c
c-c++-common/asan/pr70712.c
c-c++-common/asan/pr71480.c
c-c++-common/asan/pr79944.c
c-c++-common/asan/pr80308.c
c-c++-common/asan/swapcontext-test-1.c
gcc.dg/asan/nosanitize-and-inline.c
gcc.dg/asan/pr79196.c
gcc.dg/asan/pr80166.c
gcc.dg/asan/pr81186.c
gcc.dg/asan/use-after-scope-11.c
gcc.dg/asan/use-after-scope-4.c
gcc.dg/asan/use-after-scope-6.c
gcc.dg/asan/use-after-scope-7.c
gcc.dg/asan/use-after-scope-goto-1.c
gcc.dg/asan/use-after-scope-goto-2.c
gcc.dg/asan/use-after-scope-switch-1.c
gcc.dg/asan/use-after-scope-switch-2.c
gcc.dg/asan/use-after-scope-switch-3.c
gcc.dg/asan/use-after-scope-switch-4.c

out of which only
c-c++-common/asan/swapcontext-test-1.c
c-c++-common/asan/halt_on_error-1.c
print something in gcc.log

Do they pass for you?


Ah, I see. The problem is that after this merge LSan was enabled for ARM. LSan 
sets atexit handler that calls internal_clone function that's not supported in 
QEMU.
That's why these tests pass on board, but fail under QEMU.
Could you try set ASAN_OPTIONS=detect_leaks=0 in your environment?



Ha, thanks it works!

The remaining failure is on c-c++-common/asan/halt_on_error-1.c, which seems to 
dump the expected messages, but exits with return code=4.

Any idea ?

Thanks,

Christophe


-Maxim



Thanks,

Christophe


Thanks,
-Maxim



Thanks,

Christophe



1) We have a bunch of GCC local patches, did you include them into a
cumulative patch (I guess yes)?

I have done some verification today, diff from upstream r285547 to unpatched
GCC (with the LLVM Compiler infrastructure two liners removed), attached P1

Re: [RFC PATCH] Merge libsanitizer from upstream

[Maxim Ostapenko]

On 30/10/17 17:08, Christophe Lyon wrote:

On 30/10/2017 11:12, Maxim Ostapenko wrote:

Hi,

sorry for the late response.

On 20/10/17 13:45, Christophe Lyon wrote:

Hi,

On 19 October 2017 at 13:17, Jakub Jelinek  wrote:

On Thu, Oct 19, 2017 at 02:07:24PM +0300, Maxim Ostapenko wrote:

Is the patch (the merge + this incremental) ok for trunk?

I think the patch is OK, just wondering about two things:
Richi just approved the patch on IRC, so I'll commit, then we can 
deal with

follow-ups.


Does anyone else run these tests on arm?
Since you applied this patch, I'm seeing lots of new errors and 
timeouts.
I have been ignoring regression reports for *san because of 
yyrandomness

in the results, but the timeouts are a  major inconvenience in testing
because it increases latency a lot in getting results, or worse I 
get no

result at all because the validation job is killed before completion.

Looking at some intermediate logs, I have noticed:
==24797==AddressSanitizer CHECK failed:
/libsanitizer/asan/asan_poisoning.cc:34
"((AddrIsAlignedByGranularity(addr))) != (0)" (0x0, 0x0)
 #0 0x408d7d65 in AsanCheckFailed /libsanitizer/asan/asan_rtl.cc:67
 #1 0x408ecd5d in __sanitizer::CheckFailed(char const*, int, char
const*, unsigned long long, unsigned long long)
/libsanitizer/sanitizer_common/sanitizer_termination.cc:77
 #2 0x408d22d5 in __asan::PoisonShadow(unsigned long, unsigned
long, unsigned char) /libsanitizer/asan/asan_poisoning.cc:34
 #3 0x4085409b in __asan_register_globals
/libsanitizer/asan/asan_globals.cc:368
 #4 0x109eb in _GLOBAL__sub_I_00099_1_ten
(/aci-gcc-fsf/builds/gcc-fsf-gccsrc-thumb/obj-arm-none-linux-gnueabi/gcc3/gcc/testsuite/gcc/alloca_big_alignment.exe+0x109eb) 



in MANY (193 in gcc) tests.

and many others (152 in gcc) just time out individually (eg
c-c++-common/asan/alloca_instruments_all_paddings.c) with no error in
the logs besides Dejagnu's
WARNING: program timed out.


Since I'm using an apparently unusual setup, maybe I have to update it
to cope with the new version,
so I'd like to know if others are seeing the same problems on arm?

I'm using qemu -R 0 to execute the test programs, encapsulated by
proot (similar to chroot, but does not require root privileges).

Am I missing something obvious?


I've caught the same error on my Arndale board. The issue seems to be 
quite obvious: after merge, ASan requires globals array to be aligned 
by shadow granularity.


Thanks for confirming. I've spent a lot of time investigating the 
timeout issues, that led to zombie processes and servers needing 
reboot. I've finally identified that going back to qemu-2.7 avoid the 
timeout issues (I've reported a qemu bug).


This trivial patch seems to fix the issue. Could you check it on your 
setup?


I was just about to finally start looking at this sanity check 
problem, so thank you very much for sharing your patch.
I manually tested it on the subset of my configs and it solves the 
assertion failure, thanks!

However, I can notice many regressions compared to before the merge:
c-c++-common/asan/alloca_instruments_all_paddings.c
c-c++-common/asan/alloca_loop_unpoisoning.c
c-c++-common/asan/alloca_safe_access.c
c-c++-common/asan/asan-interface-1.c
c-c++-common/asan/halt_on_error-1.c
c-c++-common/asan/pr59063-1.c
c-c++-common/asan/pr59063-2.c
c-c++-common/asan/pr63316.c
c-c++-common/asan/pr63888.c
c-c++-common/asan/pr70712.c
c-c++-common/asan/pr71480.c
c-c++-common/asan/pr79944.c
c-c++-common/asan/pr80308.c
c-c++-common/asan/swapcontext-test-1.c
gcc.dg/asan/nosanitize-and-inline.c
gcc.dg/asan/pr79196.c
gcc.dg/asan/pr80166.c
gcc.dg/asan/pr81186.c
gcc.dg/asan/use-after-scope-11.c
gcc.dg/asan/use-after-scope-4.c
gcc.dg/asan/use-after-scope-6.c
gcc.dg/asan/use-after-scope-7.c
gcc.dg/asan/use-after-scope-goto-1.c
gcc.dg/asan/use-after-scope-goto-2.c
gcc.dg/asan/use-after-scope-switch-1.c
gcc.dg/asan/use-after-scope-switch-2.c
gcc.dg/asan/use-after-scope-switch-3.c
gcc.dg/asan/use-after-scope-switch-4.c

out of which only
c-c++-common/asan/swapcontext-test-1.c
c-c++-common/asan/halt_on_error-1.c
print something in gcc.log

Do they pass for you?


Ah, I see. The problem is that after this merge LSan was enabled for 
ARM. LSan sets atexit handler that calls internal_clone function that's 
not supported in QEMU.

That's why these tests pass on board, but fail under QEMU.
Could you try set ASAN_OPTIONS=detect_leaks=0 in your environment?

-Maxim



Thanks,

Christophe


Thanks,
-Maxim



Thanks,

Christophe



1) We have a bunch of GCC local patches, did you include them into a
cumulative patch (I guess yes)?
I have done some verification today, diff from upstream r285547 to 
unpatched
GCC (with the LLVM Compiler infrastructure two liners removed), 
attached P1,
and diff from upstream r315899 to patched GCC (again, two liners 
removed),
attached P2 and went through the changes in P1 and verified that 
except for
the ubsan backwards compatibility we had that can't work anymore 
everythin

Re: [RFC PATCH] Merge libsanitizer from upstream

[Christophe Lyon]

On 30/10/2017 11:12, Maxim Ostapenko wrote:

Hi,

sorry for the late response.

On 20/10/17 13:45, Christophe Lyon wrote:

Hi,

On 19 October 2017 at 13:17, Jakub Jelinek  wrote:

On Thu, Oct 19, 2017 at 02:07:24PM +0300, Maxim Ostapenko wrote:

Is the patch (the merge + this incremental) ok for trunk?

I think the patch is OK, just wondering about two things:

Richi just approved the patch on IRC, so I'll commit, then we can deal with
follow-ups.


Does anyone else run these tests on arm?
Since you applied this patch, I'm seeing lots of new errors and timeouts.
I have been ignoring regression reports for *san because of yyrandomness
in the results, but the timeouts are a  major inconvenience in testing
because it increases latency a lot in getting results, or worse I get no
result at all because the validation job is killed before completion.

Looking at some intermediate logs, I have noticed:
==24797==AddressSanitizer CHECK failed:
/libsanitizer/asan/asan_poisoning.cc:34
"((AddrIsAlignedByGranularity(addr))) != (0)" (0x0, 0x0)
 #0 0x408d7d65 in AsanCheckFailed /libsanitizer/asan/asan_rtl.cc:67
 #1 0x408ecd5d in __sanitizer::CheckFailed(char const*, int, char
const*, unsigned long long, unsigned long long)
/libsanitizer/sanitizer_common/sanitizer_termination.cc:77
 #2 0x408d22d5 in __asan::PoisonShadow(unsigned long, unsigned
long, unsigned char) /libsanitizer/asan/asan_poisoning.cc:34
 #3 0x4085409b in __asan_register_globals
/libsanitizer/asan/asan_globals.cc:368
 #4 0x109eb in _GLOBAL__sub_I_00099_1_ten
(/aci-gcc-fsf/builds/gcc-fsf-gccsrc-thumb/obj-arm-none-linux-gnueabi/gcc3/gcc/testsuite/gcc/alloca_big_alignment.exe+0x109eb)

in MANY (193 in gcc) tests.

and many others (152 in gcc) just time out individually (eg
c-c++-common/asan/alloca_instruments_all_paddings.c) with no error in
the logs besides Dejagnu's
WARNING: program timed out.


Since I'm using an apparently unusual setup, maybe I have to update it
to cope with the new version,
so I'd like to know if others are seeing the same problems on arm?

I'm using qemu -R 0 to execute the test programs, encapsulated by
proot (similar to chroot, but does not require root privileges).

Am I missing something obvious?


I've caught the same error on my Arndale board. The issue seems to be quite 
obvious: after merge, ASan requires globals array to be aligned by shadow 
granularity.


Thanks for confirming. I've spent a lot of time investigating the timeout 
issues, that led to zombie processes and servers needing reboot. I've finally 
identified that going back to qemu-2.7 avoid the timeout issues (I've reported 
a qemu bug).


This trivial patch seems to fix the issue. Could you check it on your setup?


I was just about to finally start looking at this sanity check problem, so 
thank you very much for sharing your patch.
I manually tested it on the subset of my configs and it solves the assertion 
failure, thanks!
However, I can notice many regressions compared to before the merge:
c-c++-common/asan/alloca_instruments_all_paddings.c
c-c++-common/asan/alloca_loop_unpoisoning.c
c-c++-common/asan/alloca_safe_access.c
c-c++-common/asan/asan-interface-1.c
c-c++-common/asan/halt_on_error-1.c
c-c++-common/asan/pr59063-1.c
c-c++-common/asan/pr59063-2.c
c-c++-common/asan/pr63316.c
c-c++-common/asan/pr63888.c
c-c++-common/asan/pr70712.c
c-c++-common/asan/pr71480.c
c-c++-common/asan/pr79944.c
c-c++-common/asan/pr80308.c
c-c++-common/asan/swapcontext-test-1.c
gcc.dg/asan/nosanitize-and-inline.c
gcc.dg/asan/pr79196.c
gcc.dg/asan/pr80166.c
gcc.dg/asan/pr81186.c
gcc.dg/asan/use-after-scope-11.c
gcc.dg/asan/use-after-scope-4.c
gcc.dg/asan/use-after-scope-6.c
gcc.dg/asan/use-after-scope-7.c
gcc.dg/asan/use-after-scope-goto-1.c
gcc.dg/asan/use-after-scope-goto-2.c
gcc.dg/asan/use-after-scope-switch-1.c
gcc.dg/asan/use-after-scope-switch-2.c
gcc.dg/asan/use-after-scope-switch-3.c
gcc.dg/asan/use-after-scope-switch-4.c

out of which only
c-c++-common/asan/swapcontext-test-1.c
c-c++-common/asan/halt_on_error-1.c
print something in gcc.log

Do they pass for you?

Thanks,

Christophe


Thanks,
-Maxim



Thanks,

Christophe



1) We have a bunch of GCC local patches, did you include them into a
cumulative patch (I guess yes)?

I have done some verification today, diff from upstream r285547 to unpatched
GCC (with the LLVM Compiler infrastructure two liners removed), attached P1,
and diff from upstream r315899 to patched GCC (again, two liners removed),
attached P2 and went through the changes in P1 and verified that except for
the ubsan backwards compatibility we had that can't work anymore everything
else was upstreamed, or remained in P2.  So P2 is the current diff from
upstream, with the sanitizer_common/sanitizer_symbolizer_libbacktrace.cc
changes now filed upstream.


2) Upstream has enabled LSan for x86 and ARM, is it worth to enable them in
GCC too?

Maybe, feel free to post patches.  For LSan we need to split off lsan_preinit
out of liblsan and lin

Re: [RFC PATCH] Merge libsanitizer from upstream

[Jakub Jelinek]

On Mon, Oct 30, 2017 at 01:12:47PM +0300, Maxim Ostapenko wrote:
> I've caught the same error on my Arndale board. The issue seems to be quite
> obvious: after merge, ASan requires globals array to be aligned by shadow
> granularity.
> This trivial patch seems to fix the issue. Could you check it on your setup?

Indeed, it now wants to poison the arrays after the registration is over.

> 2017-10-30  Maxim Ostapenko  
> 
>   * asan.c (asan_finish_file): Align asan globals array by shadow
>   granularity.

Ok, thanks.

BTW, we should investigate the 
__asan_register_elf_globals/__asan_unregister_elf_globals
and whether it is something we should start using too.

> diff --git a/gcc/asan.c b/gcc/asan.c
> index 302ac4f..d5128aa 100644
> --- a/gcc/asan.c
> +++ b/gcc/asan.c
> @@ -2942,6 +2942,9 @@ asan_finish_file (void)
>TREE_CONSTANT (ctor) = 1;
>TREE_STATIC (ctor) = 1;
>DECL_INITIAL (var) = ctor;
> +  SET_DECL_ALIGN (var, MAX (DECL_ALIGN (var),
> + ASAN_SHADOW_GRANULARITY * BITS_PER_UNIT));
> +
>varpool_node::finalize_decl (var);
>  
>tree fn = builtin_decl_implicit (BUILT_IN_ASAN_REGISTER_GLOBALS);


Jakub

Re: [RFC PATCH] Merge libsanitizer from upstream

[Maxim Ostapenko]

Hi,

sorry for the late response.

On 20/10/17 13:45, Christophe Lyon wrote:

Hi,

On 19 October 2017 at 13:17, Jakub Jelinek  wrote:

On Thu, Oct 19, 2017 at 02:07:24PM +0300, Maxim Ostapenko wrote:

Is the patch (the merge + this incremental) ok for trunk?

I think the patch is OK, just wondering about two things:

Richi just approved the patch on IRC, so I'll commit, then we can deal with
follow-ups.


Does anyone else run these tests on arm?
Since you applied this patch, I'm seeing lots of new errors and timeouts.
I have been ignoring regression reports for *san because of yyrandomness
in the results, but the timeouts are a  major inconvenience in testing
because it increases latency a lot in getting results, or worse I get no
result at all because the validation job is killed before completion.

Looking at some intermediate logs, I have noticed:
==24797==AddressSanitizer CHECK failed:
/libsanitizer/asan/asan_poisoning.cc:34
"((AddrIsAlignedByGranularity(addr))) != (0)" (0x0, 0x0)
 #0 0x408d7d65 in AsanCheckFailed /libsanitizer/asan/asan_rtl.cc:67
 #1 0x408ecd5d in __sanitizer::CheckFailed(char const*, int, char
const*, unsigned long long, unsigned long long)
/libsanitizer/sanitizer_common/sanitizer_termination.cc:77
 #2 0x408d22d5 in __asan::PoisonShadow(unsigned long, unsigned
long, unsigned char) /libsanitizer/asan/asan_poisoning.cc:34
 #3 0x4085409b in __asan_register_globals
/libsanitizer/asan/asan_globals.cc:368
 #4 0x109eb in _GLOBAL__sub_I_00099_1_ten
(/aci-gcc-fsf/builds/gcc-fsf-gccsrc-thumb/obj-arm-none-linux-gnueabi/gcc3/gcc/testsuite/gcc/alloca_big_alignment.exe+0x109eb)

in MANY (193 in gcc) tests.

and many others (152 in gcc) just time out individually (eg
c-c++-common/asan/alloca_instruments_all_paddings.c) with no error in
the logs besides Dejagnu's
WARNING: program timed out.


Since I'm using an apparently unusual setup, maybe I have to update it
to cope with the new version,
so I'd like to know if others are seeing the same problems on arm?

I'm using qemu -R 0 to execute the test programs, encapsulated by
proot (similar to chroot, but does not require root privileges).

Am I missing something obvious?


I've caught the same error on my Arndale board. The issue seems to be 
quite obvious: after merge, ASan requires globals array to be aligned by 
shadow granularity.

This trivial patch seems to fix the issue. Could you check it on your setup?

Thanks,
-Maxim



Thanks,

Christophe



1) We have a bunch of GCC local patches, did you include them into a
cumulative patch (I guess yes)?

I have done some verification today, diff from upstream r285547 to unpatched
GCC (with the LLVM Compiler infrastructure two liners removed), attached P1,
and diff from upstream r315899 to patched GCC (again, two liners removed),
attached P2 and went through the changes in P1 and verified that except for
the ubsan backwards compatibility we had that can't work anymore everything
else was upstreamed, or remained in P2.  So P2 is the current diff from
upstream, with the sanitizer_common/sanitizer_symbolizer_libbacktrace.cc
changes now filed upstream.


2) Upstream has enabled LSan for x86 and ARM, is it worth to enable them in
GCC too?

Maybe, feel free to post patches.  For LSan we need to split off lsan_preinit
out of liblsan and link it into executables, will handle it next (there is a
PR about it, just wanted to wait until the merge is in).

 Jakub





gcc/ChangeLog:

2017-10-30  Maxim Ostapenko  

	* asan.c (asan_finish_file): Align asan globals array by shadow
	granularity.

diff --git a/gcc/asan.c b/gcc/asan.c
index 302ac4f..d5128aa 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -2942,6 +2942,9 @@ asan_finish_file (void)
   TREE_CONSTANT (ctor) = 1;
   TREE_STATIC (ctor) = 1;
   DECL_INITIAL (var) = ctor;
+  SET_DECL_ALIGN (var, MAX (DECL_ALIGN (var),
+ASAN_SHADOW_GRANULARITY * BITS_PER_UNIT));
+
   varpool_node::finalize_decl (var);
 
   tree fn = builtin_decl_implicit (BUILT_IN_ASAN_REGISTER_GLOBALS);

Re: [RFC PATCH] Merge libsanitizer from upstream

[Christophe Lyon]

Hi,

On 19 October 2017 at 13:17, Jakub Jelinek  wrote:
> On Thu, Oct 19, 2017 at 02:07:24PM +0300, Maxim Ostapenko wrote:
>> > Is the patch (the merge + this incremental) ok for trunk?
>>
>> I think the patch is OK, just wondering about two things:
>
> Richi just approved the patch on IRC, so I'll commit, then we can deal with
> follow-ups.
>

Does anyone else run these tests on arm?
Since you applied this patch, I'm seeing lots of new errors and timeouts.
I have been ignoring regression reports for *san because of yyrandomness
in the results, but the timeouts are a  major inconvenience in testing
because it increases latency a lot in getting results, or worse I get no
result at all because the validation job is killed before completion.

Looking at some intermediate logs, I have noticed:
==24797==AddressSanitizer CHECK failed:
/libsanitizer/asan/asan_poisoning.cc:34
"((AddrIsAlignedByGranularity(addr))) != (0)" (0x0, 0x0)
#0 0x408d7d65 in AsanCheckFailed /libsanitizer/asan/asan_rtl.cc:67
#1 0x408ecd5d in __sanitizer::CheckFailed(char const*, int, char
const*, unsigned long long, unsigned long long)
/libsanitizer/sanitizer_common/sanitizer_termination.cc:77
#2 0x408d22d5 in __asan::PoisonShadow(unsigned long, unsigned
long, unsigned char) /libsanitizer/asan/asan_poisoning.cc:34
#3 0x4085409b in __asan_register_globals
/libsanitizer/asan/asan_globals.cc:368
#4 0x109eb in _GLOBAL__sub_I_00099_1_ten
(/aci-gcc-fsf/builds/gcc-fsf-gccsrc-thumb/obj-arm-none-linux-gnueabi/gcc3/gcc/testsuite/gcc/alloca_big_alignment.exe+0x109eb)

in MANY (193 in gcc) tests.

and many others (152 in gcc) just time out individually (eg
c-c++-common/asan/alloca_instruments_all_paddings.c) with no error in
the logs besides Dejagnu's
WARNING: program timed out.


Since I'm using an apparently unusual setup, maybe I have to update it
to cope with the new version,
so I'd like to know if others are seeing the same problems on arm?

I'm using qemu -R 0 to execute the test programs, encapsulated by
proot (similar to chroot, but does not require root privileges).

Am I missing something obvious?

Thanks,

Christophe


>> 1) We have a bunch of GCC local patches, did you include them into a
>> cumulative patch (I guess yes)?
>
> I have done some verification today, diff from upstream r285547 to unpatched
> GCC (with the LLVM Compiler infrastructure two liners removed), attached P1,
> and diff from upstream r315899 to patched GCC (again, two liners removed),
> attached P2 and went through the changes in P1 and verified that except for
> the ubsan backwards compatibility we had that can't work anymore everything
> else was upstreamed, or remained in P2.  So P2 is the current diff from
> upstream, with the sanitizer_common/sanitizer_symbolizer_libbacktrace.cc
> changes now filed upstream.
>
>> 2) Upstream has enabled LSan for x86 and ARM, is it worth to enable them in
>> GCC too?
>
> Maybe, feel free to post patches.  For LSan we need to split off lsan_preinit
> out of liblsan and link it into executables, will handle it next (there is a
> PR about it, just wanted to wait until the merge is in).
>
> Jakub

Re: [RFC PATCH] Merge libsanitizer from upstream

[Eric Gallager]

On 10/19/17, Jakub Jelinek  wrote:
> On Thu, Oct 19, 2017 at 02:07:24PM +0300, Maxim Ostapenko wrote:
>> > Is the patch (the merge + this incremental) ok for trunk?
>>
>> I think the patch is OK, just wondering about two things:
>
> Richi just approved the patch on IRC, so I'll commit, then we can deal with
> follow-ups.
>
>> 1) We have a bunch of GCC local patches, did you include them into a
>> cumulative patch (I guess yes)?
>
> I have done some verification today, diff from upstream r285547 to
> unpatched
> GCC (with the LLVM Compiler infrastructure two liners removed), attached
> P1,
> and diff from upstream r315899 to patched GCC (again, two liners removed),
> attached P2 and went through the changes in P1 and verified that except for
> the ubsan backwards compatibility we had that can't work anymore everything
> else was upstreamed, or remained in P2.  So P2 is the current diff from
> upstream, with the sanitizer_common/sanitizer_symbolizer_libbacktrace.cc
> changes now filed upstream.
>
>> 2) Upstream has enabled LSan for x86 and ARM, is it worth to enable them
>> in GCC too?
>
> Maybe, feel free to post patches.  For LSan we need to split off
> lsan_preinit
> out of liblsan and link it into executables, will handle it next (there is
> a PR about it, just wanted to wait until the merge is in).
>

Just for reference, the PR number is bug 82595 btw, for anyone reading
who isn't already on it:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82595

>   Jakub
>

Re: [RFC PATCH] Merge libsanitizer from upstream

[Kamil Rytarowski]

On 19.10.2017 13:17, Jakub Jelinek wrote:
> On Thu, Oct 19, 2017 at 02:07:24PM +0300, Maxim Ostapenko wrote:
>>> Is the patch (the merge + this incremental) ok for trunk?
>>
>> I think the patch is OK, just wondering about two things:
> 
> Richi just approved the patch on IRC, so I'll commit, then we can deal with
> follow-ups.
> 
>> 1) We have a bunch of GCC local patches, did you include them into a
>> cumulative patch (I guess yes)?
> 
> I have done some verification today, diff from upstream r285547 to unpatched
> GCC (with the LLVM Compiler infrastructure two liners removed), attached P1,
> and diff from upstream r315899 to patched GCC (again, two liners removed),
> attached P2 and went through the changes in P1 and verified that except for
> the ubsan backwards compatibility we had that can't work anymore everything
> else was upstreamed, or remained in P2.  So P2 is the current diff from
> upstream, with the sanitizer_common/sanitizer_symbolizer_libbacktrace.cc
> changes now filed upstream.
> 
>> 2) Upstream has enabled LSan for x86 and ARM, is it worth to enable them in
>> GCC too?
> 
> Maybe, feel free to post patches.  For LSan we need to split off lsan_preinit
> out of liblsan and link it into executables, will handle it next (there is a
> PR about it, just wanted to wait until the merge is in).
> 
>   Jakub
> 

NetBSD/amd64 ships now with asan, ubsan, libfuzzer (WIP) and safestack
upstreamed.

tsan is work-in-progress and it will be followed by msan.

"make check-tsan" with local patches results so far:

Expected Passes: 248
Expected Failures  : 1
Unsupported Tests  : 83
Unexpected Failures: 44

It's worth to enable the upstreamed features on the GCC/NetBSD frontend
as well. We are doing it currently downstream in the NetBSD distribution.



signature.asc
Description: OpenPGP digital signature

Re: [RFC PATCH] Merge libsanitizer from upstream

[Jakub Jelinek]

On Thu, Oct 19, 2017 at 02:07:24PM +0300, Maxim Ostapenko wrote:
> > Is the patch (the merge + this incremental) ok for trunk?
> 
> I think the patch is OK, just wondering about two things:

Richi just approved the patch on IRC, so I'll commit, then we can deal with
follow-ups.

> 1) We have a bunch of GCC local patches, did you include them into a
> cumulative patch (I guess yes)?

I have done some verification today, diff from upstream r285547 to unpatched
GCC (with the LLVM Compiler infrastructure two liners removed), attached P1,
and diff from upstream r315899 to patched GCC (again, two liners removed),
attached P2 and went through the changes in P1 and verified that except for
the ubsan backwards compatibility we had that can't work anymore everything
else was upstreamed, or remained in P2.  So P2 is the current diff from
upstream, with the sanitizer_common/sanitizer_symbolizer_libbacktrace.cc
changes now filed upstream.

> 2) Upstream has enabled LSan for x86 and ARM, is it worth to enable them in
> GCC too?

Maybe, feel free to post patches.  For LSan we need to split off lsan_preinit
out of liblsan and link it into executables, will handle it next (there is a
PR about it, just wanted to wait until the merge is in).

Jakub
--- /usr/src/llvm/projects/compiler-rt.285547/lib/asan/asan_globals.cc  
2017-10-19 10:29:52.916249242 +0200
+++ asan/asan_globals.cc2017-10-19 09:17:31.163837518 +0200
@@ -149,23 +147,6 @@ static void CheckODRViolationViaIndicato
   }
 }
 
-// Check ODR violation for given global G by checking if it's already poisoned.
-// We use this method in case compiler doesn't use private aliases for global
-// variables.
-static void CheckODRViolationViaPoisoning(const Global *g) {
-  if (__asan_region_is_poisoned(g->beg, g->size_with_redzone)) {
-// This check may not be enough: if the first global is much larger
-// the entire redzone of the second global may be within the first global.
-for (ListOfGlobals *l = list_of_all_globals; l; l = l->next) {
-  if (g->beg == l->g->beg &&
-  (flags()->detect_odr_violation >= 2 || g->size != l->g->size) &&
-  !IsODRViolationSuppressed(g->name))
-ReportODRViolation(g, FindRegistrationSite(g),
-   l->g, FindRegistrationSite(l->g));
-}
-  }
-}
-
 // Clang provides two different ways for global variables protection:
 // it can poison the global itself or its private alias. In former
 // case we may poison same symbol multiple times, that can help us to
@@ -213,8 +194,6 @@ static void RegisterGlobal(const Global
 // where two globals with the same name are defined in different modules.
 if (UseODRIndicator(g))
   CheckODRViolationViaIndicator(g);
-else
-  CheckODRViolationViaPoisoning(g);
   }
   if (CanPoisonMemory())
 PoisonRedZones(*g);
--- 
/usr/src/llvm/projects/compiler-rt.285547/lib/sanitizer_common/sanitizer_common_interceptors.inc
2017-10-19 10:29:53.330243835 +0200
+++ sanitizer_common/sanitizer_common_interceptors.inc  2017-10-19 
09:17:31.139837810 +0200
@@ -3352,7 +3350,8 @@ INTERCEPTOR(int, getgroups, int size, u3
   // its metadata. See
   // https://github.com/google/sanitizers/issues/321.
   int res = REAL(getgroups)(size, lst);
-  if (res && lst) COMMON_INTERCEPTOR_WRITE_RANGE(ctx, lst, res * sizeof(*lst));
+  if (res >= 0 && lst && size > 0)
+COMMON_INTERCEPTOR_WRITE_RANGE(ctx, lst, res * sizeof(*lst));
   return res;
 }
 #define INIT_GETGROUPS COMMON_INTERCEPT_FUNCTION(getgroups);
@@ -4552,11 +4551,15 @@ void *__tls_get_addr_opt(void *arg);
 //   descriptor offset as an argument instead of a pointer.  GOT address
 //   is passed in r12, so it's necessary to write it in assembly.  This is
 //   the function used by the compiler.
-#define INIT_TLS_GET_ADDR COMMON_INTERCEPT_FUNCTION(__tls_get_addr_internal)
+extern "C" uptr __tls_get_offset_wrapper(void *arg, uptr (*fn)(void *arg));
+#define INIT_TLS_GET_ADDR COMMON_INTERCEPT_FUNCTION(__tls_get_offset)
+DEFINE_REAL(uptr, __tls_get_offset, void *arg)
+extern "C" uptr __tls_get_offset(void *arg);
+extern "C" uptr __interceptor___tls_get_offset(void *arg);
 INTERCEPTOR(uptr, __tls_get_addr_internal, void *arg) {
   void *ctx;
   COMMON_INTERCEPTOR_ENTER(ctx, __tls_get_addr_internal, arg);
-  uptr res = REAL(__tls_get_addr_internal)(arg);
+  uptr res = __tls_get_offset_wrapper(arg, REAL(__tls_get_offset));
   uptr tp = reinterpret_cast(__builtin_thread_pointer());
   void *ptr = reinterpret_cast(res + tp);
   uptr tls_begin, tls_end;
@@ -4568,32 +4571,43 @@ INTERCEPTOR(uptr, __tls_get_addr_interna
   }
   return res;
 }
-// We need a protected symbol aliasing the above, so that we can jump
+// We need a hidden symbol aliasing the above, so that we can jump
 // directly to it from the assembly below.
 extern "C" __attribute__((alias("__interceptor___tls_get_addr_internal"),
-  visibility("protected")))
-uptr __interceptor___tls_get_addr_internal_protecte

Re: [RFC PATCH] Merge libsanitizer from upstream

[Maxim Ostapenko]

Hi, I'm sorry for a late response.

On 19/10/17 13:52, Jakub Jelinek wrote:

On Mon, Oct 16, 2017 at 08:52:50PM +0200, Jakub Jelinek wrote:

The following patch is an attempt at libsanitizer merge from upstream.
Sadly libubsan has several ABI incompatible changes, dunno if we should
fight the mess and re-add backward compatibility back, or as the patch
does just bump soname, upstream clearly doesn't care about ABI compatibility
at all.

Bootstrapped/regtested on x86_64-linux and i686-linux, it would be nice to
get it tested on other targets (e.g. darwin, that breaks almost all the time
when doing merges, but no access to that).

Included is just the non-libsanitizer/ part plus GCC owned file changes
in libsanitizer (except regenerated ones), attached is bzip2ed full patch.

Thoughts on this?

Seems I've missed two test failures during the testing, this incremental patch 
ought
to fix that (with LTO we optimize away __asan_default_options and thus the
test fails, and libasan changed the env var handling, instead of having
handle_segv={0,1} it now has {0,1,2} modes and the old default 1 mode is now
the non-default mode 2, which the test relies on.

To answer my own question about possibility to avoid libubsan soname bump,
seems that is really not possible, because they removed already before
last merge __ubsan_handle_cfi_bad_type{,_abort} entrypoints (which we've
added back to make the library backwards compatible), but now they have
added __ubsan_handle_cfi_bad_type again with a different signature!
Argh!

Is the patch (the merge + this incremental) ok for trunk?


I think the patch is OK, just wondering about two things:

1) We have a bunch of GCC local patches, did you include them into a 
cumulative patch (I guess yes)?
2) Upstream has enabled LSan for x86 and ARM, is it worth to enable them 
in GCC too?


-Maxim



2017-10-19  Jakub Jelinek  

* g++.dg/asan/default-options-1.C (__asan_default_options): Add
used attribute.
* g++.dg/asan/asan_test.C: Run with ASAN_OPTIONS=handle_segv=2
in the environment.

--- gcc/testsuite/g++.dg/asan/default-options-1.C.jj2015-10-29 
09:14:39.0 +0100
+++ gcc/testsuite/g++.dg/asan/default-options-1.C   2017-10-19 
12:09:26.367324880 +0200
@@ -3,7 +3,7 @@
  const char *kAsanDefaultOptions="verbosity=1 foo=bar";
  
  extern "C"

-__attribute__((no_sanitize_address))
+__attribute__((no_sanitize_address, used))
  const char *__asan_default_options() {
return kAsanDefaultOptions;
  }
--- gcc/testsuite/g++.dg/asan/asan_test.C.jj2017-01-24 09:27:20.0 
+0100
+++ gcc/testsuite/g++.dg/asan/asan_test.C   2017-10-19 12:06:27.453510604 
+0200
@@ -8,6 +8,7 @@
  // { dg-additional-options "-DASAN_AVOID_EXPENSIVE_TESTS=1" { target { ! 
run_expensive_tests } } }
  // { dg-additional-options "-msse2" { target { i?86-*-linux* x86_64-*-linux* 
} } }
  // { dg-additional-options "-D__NO_INLINE__" { target { *-*-linux-gnu } } }
+// { dg-set-target-env-var ASAN_OPTIONS "handle_segv=2" }
  // { dg-final { asan-gtest } }
  
  #include "asan_test.cc"



Jakub

Re: [RFC PATCH] Merge libsanitizer from upstream

[Jakub Jelinek]

On Mon, Oct 16, 2017 at 08:52:50PM +0200, Jakub Jelinek wrote:
> The following patch is an attempt at libsanitizer merge from upstream.
> Sadly libubsan has several ABI incompatible changes, dunno if we should
> fight the mess and re-add backward compatibility back, or as the patch
> does just bump soname, upstream clearly doesn't care about ABI compatibility
> at all.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, it would be nice to
> get it tested on other targets (e.g. darwin, that breaks almost all the time
> when doing merges, but no access to that).
> 
> Included is just the non-libsanitizer/ part plus GCC owned file changes
> in libsanitizer (except regenerated ones), attached is bzip2ed full patch.
> 
> Thoughts on this?

Seems I've missed two test failures during the testing, this incremental patch 
ought
to fix that (with LTO we optimize away __asan_default_options and thus the
test fails, and libasan changed the env var handling, instead of having
handle_segv={0,1} it now has {0,1,2} modes and the old default 1 mode is now
the non-default mode 2, which the test relies on.

To answer my own question about possibility to avoid libubsan soname bump,
seems that is really not possible, because they removed already before
last merge __ubsan_handle_cfi_bad_type{,_abort} entrypoints (which we've
added back to make the library backwards compatible), but now they have
added __ubsan_handle_cfi_bad_type again with a different signature!
Argh!

Is the patch (the merge + this incremental) ok for trunk?

2017-10-19  Jakub Jelinek  

* g++.dg/asan/default-options-1.C (__asan_default_options): Add
used attribute.
* g++.dg/asan/asan_test.C: Run with ASAN_OPTIONS=handle_segv=2
in the environment.

--- gcc/testsuite/g++.dg/asan/default-options-1.C.jj2015-10-29 
09:14:39.0 +0100
+++ gcc/testsuite/g++.dg/asan/default-options-1.C   2017-10-19 
12:09:26.367324880 +0200
@@ -3,7 +3,7 @@
 const char *kAsanDefaultOptions="verbosity=1 foo=bar";
 
 extern "C"
-__attribute__((no_sanitize_address))
+__attribute__((no_sanitize_address, used))
 const char *__asan_default_options() {
   return kAsanDefaultOptions;
 }
--- gcc/testsuite/g++.dg/asan/asan_test.C.jj2017-01-24 09:27:20.0 
+0100
+++ gcc/testsuite/g++.dg/asan/asan_test.C   2017-10-19 12:06:27.453510604 
+0200
@@ -8,6 +8,7 @@
 // { dg-additional-options "-DASAN_AVOID_EXPENSIVE_TESTS=1" { target { ! 
run_expensive_tests } } }
 // { dg-additional-options "-msse2" { target { i?86-*-linux* x86_64-*-linux* } 
} }
 // { dg-additional-options "-D__NO_INLINE__" { target { *-*-linux-gnu } } }
+// { dg-set-target-env-var ASAN_OPTIONS "handle_segv=2" }
 // { dg-final { asan-gtest } }
 
 #include "asan_test.cc"


Jakub