On 07/05/2018 12:01 PM, Jakub Jelinek wrote:
> On Wed, Jul 04, 2018 at 08:20:47PM +0300, Maxim Ostapenko wrote:
>> On 07/04/2018 05:45 AM, Jeff Law wrote:
>>> On 05/23/2018 11:15 AM, Maxim Ostapenko wrote:
>>>> as described in PR, when using both ASan and UBSan
>
Hi Jeff,
On 07/04/2018 05:45 AM, Jeff Law wrote:
> On 05/23/2018 11:15 AM, Maxim Ostapenko wrote:
>> Hi,
>>
>>
>> as described in PR, when using both ASan and UBSan
>> (-fsanitize=address,undefined ), we have symbols collision for global
>> functions, like
Hi,
On 06/10/2018 09:49 PM, Jakub Jelinek wrote:
> On Fri, Jun 08, 2018 at 08:10:40PM +0300, Denis Khalikov wrote:
>> From: Denis Khalikov
>> Date: Fri, 8 Jun 2018 19:53:01 +0300
>> Subject: [PATCH] PR sanitizer/86090
>>
>> * configure.ac: Check for lstat and readlink.
>> * configure, config.h.i
ttached patch fixes the symbols collision by embedding UBSan into
ASan (variant 1), just like we do for LSan.
Regtested/bootstrapped on x86_64-unknown-linux-gnu, looks reasonable
enough for trunk?
-Maxim
gcc/ChangeLog:
2018-05-23 Maxim Ostapenko
* config/gnu-user.h (LIBASAN_EARLY_SPEC): Pa
On 04/13/2018 01:16 AM, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, we need to unpoison the red zones when leaving a
> scope with VLA variable(s); this is done through __asan_allocas_unpoison
> call, unfortunately it is called after the __builtin_stack_restore which
> restores the stack
On 03/19/2018 07:35 PM, Jakub Jelinek wrote:
On Mon, Mar 19, 2018 at 07:28:11PM +0300, Maxim Ostapenko wrote:
Yes, it works, attaching the patch.
Can you please add a short comment why we do this? Also, the testcase
needs work, see below. Ok for trunk with those changes and after a
while for
On 03/19/2018 06:55 PM, Jakub Jelinek wrote:
On Mon, Mar 19, 2018 at 06:44:39PM +0300, Maxim Ostapenko wrote:
as noted in bugzilla, ASan inserts redzones for `.LDFCM*' variables and
breaks internal ABI between GCC and libstdc++ because libstdc++ tries to
obtain a pointer to `typeinf
eLog:
PR sanitizer/78651
* g++.dg/asan/pr78651.C: New test.
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index b5b5559..a26f05e 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,12 @@
+2018-03-19 Maxim Ostapenko
+
+ PR sanitizer/78651
+ * dwarf2asm.c (dw2_output_indirect_constant_1): Ca
Ok, thanks, here is the patch I'm going to install after bootstrap
completes.
On 30/11/17 14:54, Jakub Jelinek wrote:
On Thu, Nov 30, 2017 at 02:38:25PM +0300, Maxim Ostapenko wrote:
Hi Jakub, thanks for review.
I've fixed the issues you've pointed in review.
Regarding a t
n arm-linux and x86_64-linux, bootstrap is in
progress.
Thanks,
-Maxim
On 29/11/17 13:10, Jakub Jelinek wrote:
On Tue, Nov 28, 2017 at 10:04:51AM +0300, Maxim Ostapenko wrote:
(CC'ing Jakub and Ramana)
I would like to ping the following patch:
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg0228
(CC'ing Jakub and Ramana)
Hi,
I would like to ping the following patch:
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg02288.html
Fix Incorrect ASan global variables alignment on arm (PR sanitizer/81697)
-Maxim
gcc/ChangeLog:
2017-11-28 Maxim Ostapenko
PR sanitizer/81697
* a
Hi,
I would like to ping the following patch:
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg02288.html
Thanks,
-Maxim
gcc/ChangeLog:
2017-11-21 Maxim Ostapenko
PR sanitizer/81697
* asan.c (asan_protect_global): Add new ignore_decl_rtl_set_p
parameter. Return true if
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
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
Hi,
I would like to ping the following patch:
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg02288.html
Thanks,
-Maxim
gcc/ChangeLog:
2017-11-13 Maxim Ostapenko
PR sanitizer/81697
* asan.c (asan_protect_global): Add new ignore_decl_rtl_set_p
parameter. Return true if
ueabi, ppc64-unknown-linux-gnu and x86{,
_64}-linux-gnu, bootstrapped on x86_64-unknown-linux-gnu.
-Maxim
gcc/ChangeLog:
2017-10-31 Maxim Ostapenko
PR sanitizer/81697
* asan.c (asan_protect_global): Add new ignore_decl_rtl_set_p
parameter. Return true if ignore_decl_rtl_set_p is true and
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
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
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
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
Hi Ian,
On 12/09/17 17:05, Ian Lance Taylor via gcc-patches wrote:
On Mon, Sep 11, 2017 at 3:06 AM, Denis Khalikov
wrote:
Thanks for answer.
I understood all points which you mentioned, but can't
find last one
It seems to work
out the file name a second time, even though the file name must
al
+ Jakub
On 09/08/17 19:21, Jeff Law wrote:
On 08/08/2017 12:46 AM, Vyacheslav Barinov wrote:
Hello,
Andrew Pinski writes:
On Mon, Aug 7, 2017 at 11:15 PM, Slava Barinov wrote:
gcc/
* varasm.c (use_object_blocks_p): Forbid section anchors for ASan
gcc/testsuite/
tting
ix86_stack_protector_guard_reg thus all related options are propagated
correctly.
Tested on x86{_64}-unknown-linux-gnu and lto-bootstrapped, OK to apply?
-Maxim
gcc/ChangeLog:
2017-08-17 Maxim Ostapenko
PR target/81861
* config/i386/i386.c (ix86_option_override_internal): Save target
specific op
On 11/07/17 17:56, Andreas Schwab wrote:
On Jul 11 2017, Maxim Ostapenko wrote:
diff --git a/gcc/builtins.c b/gcc/builtins.c
index 608993a..6437979 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -4976,9 +4976,7 @@ expand_asan_emit_allocas_unpoison (tree exp
On 11/07/17 16:51, Andreas Schwab wrote:
On Jul 10 2017, Maxim Ostapenko wrote:
diff --git a/gcc/asan.c b/gcc/asan.c
index 95004d7..89c2731 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -1567,9 +1567,10 @@ asan_emit_allocas_unpoison (rtx top, rtx bot, rtx_insn
*before)
else
Hi Andreas,
On 08/07/17 21:48, Andreas Schwab wrote:
This breaks gcc.dg/asan/pr80168.c on aarch64 -mabi=ilp32:
/opt/gcc/gcc-20170708/gcc/testsuite/gcc.dg/asan/pr80168.c:7:1: internal
compiler error: in emit_library_call_value_1, at calls.c:4555
0x701577 emit_library_call_value_1
../..
ument-allocas=0/1 (on by default for userspace and off for
kernel) to avoid the issue.
Tested on x86_64-unknown-linux-gnu, OK after
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00258.html will be applied?
-Maxim
gcc/ChangeLog:
2017-07-06 Maxim Ostapenko
* asan.h (asan_sanitize_allo
e the replace_call_with_value call, the rest
is just try if it works and if it doesn't, keep what you have.
gcc/ChangeLog:
2017-07-05 Maxim Ostapenko
* asan.c: Include gimple-fold.h.
(get_last_alloca_addr): New function.
(handle_builtin_stackrestore): Likewise.
(handle_builtin_alloca)
On 05/07/17 12:34, Jakub Jelinek wrote:
On Wed, Jul 05, 2017 at 11:24:15AM +0300, Maxim Ostapenko wrote:
+ In general, can't we use new_sp as bot parameter because on some
s/can't we/we can't/
+ /* new_alloca = new_alloca_with_rz + align. */
+ g = gimple_build_assign
Hi,
this is a patch with fixed issues for previous review. Tested and
bootstrapped on x86_64-unknown-linux-gnu and ppc64le-redhat-linux.
Could you take a look?
-Maxim
gcc/ChangeLog:
2017-07-05 Maxim Ostapenko
* asan.c: Include gimple-fold.h.
(get_last_alloca_addr): New function
Hi,
On 29/06/17 15:35, Jakub Jelinek wrote:
Hi!
Sorry for the review delay.
On Mon, Jun 26, 2017 at 03:49:23PM +0300, Maxim Ostapenko wrote:
(handle_builtin_stackrestore): Likewise.
The function is called with _ between stack and restore.
* match.pd: Add new pattern
e know that corresponding
bits are zero, but I'm not sure this pattern has a practical value.
Tested and bootstrapped on x86_64-unknown-linux-gnu. Could you take a look?
-Maxim
gcc/ChangeLog:
2017-06-26 Maxim Ostapenko
* asan.c: Include gimple-fold.h.
(get_last_alloc
raden Obrzut
Carlos O'Donell
Peter O'Gorman
Andrea Ornstein
+Maxim Ostapenko
Patrick Palka
Devang Patel
Andris Pavenis
Hi Jakub,
thank you for your points. I've updated the patch.
-Maxim
gcc/ChangeLog:
2017-06-14 Maxim Ostapenko
* asan.c: Include gimple-fold.h.
(get_last_alloca_addr): New function.
(handle_builtin_stackrestore): Likewise.
(handle_builtin_alloca): Lik
Hi,
I would like to ping the following patch:
https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01374.html
Rebased version is attached.
Thanks,
-Maxim
gcc/ChangeLog:
2017-06-13 Maxim Ostapenko
* asan.c: Include gimple-fold.h.
(get_last_alloca_addr): New function
Hi,
I would like to ping this patch:
https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01374.html
Thanks,
-Maxim
Hi,
could someone take a look on this patch:
https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01374.html ?
Thanks,
-Maxim
ensible for GCC? Any feedback/suggestions would
be greatly appreciated.
Thanks,
-Maxim
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72765
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80798
[3] https://github.com/radare/radare2/issues/6918
gcc/ChangeLog:
2017-05-17 Maxim Ostapenko
* as
Hi,
I've applied the patch for Denis in r246909. Also, the issue seems to
appear at least in GCC 6 (and perhaps in 5, I need to check).
Is it OK to apply the patch on branches after testing?
-Maxim
On 13/04/17 17:03, Jakub Jelinek wrote:
On Thu, Apr 13, 2017 at 04:55:52PM +0300, Denis Khalik
Hi,
this patch fixes 'dyld: Symbol not found: _memmem' linkage error on
Darwin 10.6.
Just cherry-pick r293992 from upstream, OK to apply?
-Maxim
libsanitizer/ChangeLog:
2017-02-03 Maxim Ostapenko
PR sanitizer/78663
* sanitizer_common/sanitizer_mac.cc: Cherry-pick upstre
Hi,
PR lto/79061 actually affects gcc-{5, 6}-branch too
Is it OK to apply following patch on branches?
-Maxim
gcc/ChangeLog:
2017-02-02 Maxim Ostapenko
PR lto/79061
* asan.c (asan_add_global): Force has_dynamic_init to zero in LTO mode.
diff --git a/gcc/asan.c b/gcc/asan.c
index 398a508
86_64-unknown-linux-gnu, OK to apply?
Or do I need to cook a proper fix for GCC 7 (and branches) and come back
then?
-Maxim
gcc/ChangeLog:
2017-01-30 Maxim Ostapenko
* asan.c (get_translation_unit_decl): Remove function.
(asan_add_global): Force has_dynamic_init to zero in LTO mode.
diff --
TRANSLATION_UNIT_DECL instead of creating new source location.
OK to install if regtest and bootstrap complete successfully? I've also
checked that new patch doesn't introduce compile-time regression on
aermod.f90 testcase.
Thanks,
-Maxim
gcc/fortran/ChangeLog:
2017-01-24 Maxim Ostapenko
*
On 23/01/17 12:03, Richard Biener wrote:
On Wed, 18 Jan 2017, Maxim Ostapenko wrote:
On 18/01/17 16:00, Richard Biener wrote:
On Wed, 18 Jan 2017, Maxim Ostapenko wrote:
Hi,
as was figured out in PR LTO + ASan raises false initialization order
fiasco
alarm due to in LTO case
On 18/01/17 16:00, Richard Biener wrote:
On Wed, 18 Jan 2017, Maxim Ostapenko wrote:
Hi,
as was figured out in PR LTO + ASan raises false initialization order fiasco
alarm due to in LTO case main_input_filename doesn't match module name passed
to __asan_before_dynamic_init.
Following Ja
TION_UNIT_DECL, but I
wonder if more reliable fix is possible.
Attached patch fixes the issue mentioned in PR and passes regression
testing and LTO bootstrap on x86_64-unknown-linux-gnu.
Could you please take a look on it?
-Maxim
gcc/lto/ChangeLog:
2017-01-17 Maxim Ostapenko
* lto.c (lt
On 13/01/17 11:24, Jakub Jelinek wrote:
On Fri, Jan 13, 2017 at 11:19:19AM +0300, Maxim Ostapenko wrote:
as mentioned in PR, Linux kernel 4.9 fails to build with ASan due to wrong
handling of emitted ODR indicator symbols. Although this might be a kernel
bug (relying on specific pattern in
sable them if -fsanitize=kernel-address is present.
Tested on x86_64-unknown-linux-gnu, OK for trunk?
-Maxim
gcc/ChangeLog:
2017-01-13 Maxim Ostapenko
PR sanitizer/78887
* asan.c (asan_needs_odr_indicator_p): Don't emit ODR indicators
if -fsanitize=kernel-address is present.
diff -
On 11/01/17 14:17, Richard Biener wrote:
On Wed, Jan 11, 2017 at 10:00 AM, Maxim Ostapenko
wrote:
Hi,
as mentioned in PR, LTO doesn't propagate node->dynamically_initialized bit
for varpool nodes that leads to ASan fails to detect initialization order
fiasco even for trivial exam
o).
This trivial patch fixes the issue. Regtested on
x86_64-unknown-linux-gnu, OK for mainline?
-Maxim
gcc/ChangeLog:
2017-01-11 Maxim Ostapenko
PR lto/79042
* lto-cgraph.c (lto_output_varpool_node): Pack dynamically_initialized
bit.
(input_varpool_node): Unpack dynamically_initialized bi
Jakub, thank you for review. I'll commit following patch if no issues
occur after regtesting and bootstrapping.
On 01/12/16 13:42, Jakub Jelinek wrote:
On Thu, Dec 01, 2016 at 01:25:43PM +0300, Maxim Ostapenko wrote:
+ int len = strlen (IDENTIFIER_POINTER (decl_name))
+ + s
w?
Tested and ASan bootstrapped on x86_64-unknown-linux-gnu.
-Maxim
commit 35cb5eb935bb1e29357e93f8e9a4e87fb4e9f511
Author: Maxim Ostapenko
Date: Fri Oct 28 10:22:03 2016 +0300
Add support for ASan odr_indicator.
config/
* bootstrap-asan.mk: Replace LSAN_OPTIONS=detect_le
Hi,
this patch restores libsanitizer build on sparc64-linux-gnu with Glibc
2.20+ on board.
I verified that this patch fixes the build error locally with Glibc 2.24.
Ok for mainline?
libsanitizer/ChangeLog:
2016-11-30 Maxim Ostapenko
PR sanitizer/78532
* sanitizer_common
On 21/11/16 15:17, Jakub Jelinek wrote:
On Mon, Nov 21, 2016 at 12:09:30PM +, Yuri Gribov wrote:
On Mon, Nov 21, 2016 at 11:50 AM, Jakub Jelinek wrote:
On Mon, Nov 21, 2016 at 11:43:56AM +, Yuri Gribov wrote:
This is just weird. DECL_NAME in theory could be NULL, or can be a symbol
m
On 21/11/16 15:17, Jakub Jelinek wrote:
On Mon, Nov 21, 2016 at 12:09:30PM +, Yuri Gribov wrote:
On Mon, Nov 21, 2016 at 11:50 AM, Jakub Jelinek wrote:
On Mon, Nov 21, 2016 at 11:43:56AM +, Yuri Gribov wrote:
This is just weird. DECL_NAME in theory could be NULL, or can be a symbol
m
Hi,
I would like to ping the following patch:
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01300.html.
-Maxim
On 16/11/16 14:00, Jakub Jelinek wrote:
On Fri, Nov 11, 2016 at 06:32:43PM +0300, Maxim Ostapenko wrote:
Tested on x86_64-unknown-linux-gnu. OK for mainline?
Ok (though the LOCAL_PATCHES file is missing in the patch).
Yes, I'm going to commit it in separate revision.
libsani
* c-c++-common/asan/no-redundant-odr-indicators-1.c: New test.
diff --git a/config/ChangeLog b/config/ChangeLog
index 3b0092b..0c75185 100644
--- a/config/ChangeLog
+++ b/config/ChangeLog
@@ -1,3 +1,8 @@
+2016-11-14 Maxim Ostapenko
+
+ * bootstrap-asan.mk: Replace LSAN_OPTIONS=detect_leaks=0
trace_gep
__sanitizer_cov_trace_pc_guard
__sanitizer_cov_trace_pc_indir
internal_sigreturn
Tested on x86_64-unknown-linux-gnu. OK for mainline?
-Maxim
libsanitizer/ChangeLog:
2016-11-11 Maxim Ostapenko
PR sanitizer/78307
* ubsan/ubsan_handlers.cc (__ubsan_handle_cfi_bad_icall): New function.
On 07/11/16 13:04, Jakub Jelinek wrote:
On Mon, Nov 07, 2016 at 11:22:28AM +0300, Maxim Ostapenko wrote:
Hi,
this patch set performs libsanitizer merge from upstream.
Patch 1 is the library merge itself.
Patch 2 is the reapplied change for SPARC by David S. Miller.
Patch 3 changes heuristic
On 07/11/16 12:20, Jakub Jelinek wrote:
On Mon, Nov 07, 2016 at 12:14:39PM +0300, Maxim Ostapenko wrote:
libubsan is definitely compatible.
Nice.
For libtsan we have several changes:
1) Several interceptors (34 of them) were added and __interceptor_lstat{64}
were removed.
That is bad, I
On 07/11/16 12:28, Yuri Gribov wrote:
On Mon, Nov 7, 2016 at 9:20 AM, Jakub Jelinek wrote:
On Mon, Nov 07, 2016 at 12:14:39PM +0300, Maxim Ostapenko wrote:
libubsan is definitely compatible.
Nice.
For libtsan we have several changes:
1) Several interceptors (34 of them) were added and
On 07/11/16 11:39, Jakub Jelinek wrote:
On Mon, Nov 07, 2016 at 11:22:28AM +0300, Maxim Ostapenko wrote:
this patch set performs libsanitizer merge from upstream.
Patch 1 is the library merge itself.
Patch 2 is the reapplied change for SPARC by David S. Miller.
Patch 3 changes heuristic
) the odr indicator is not needed, thus we can skip the
indicator for them and pass zero to runtime.
If this patch is undesirable at this stage, we can probably postpone it
until GCC 8 though.
From 137f139972a89259b9d8521e13ecb76fd2cef433 Mon Sep 17 00:00:00 2001
From: Maxim Ostapenko
Date: Fri
This patch just adds several tests backported from upstream.
From b4677ed64e7aee1af7772750e0b18ed8271f4757 Mon Sep 17 00:00:00 2001
From: Maxim Ostapenko
Date: Tue, 1 Nov 2016 16:52:13 +0300
Subject: [PATCH 6/7] Backport several testcases for ASan from upstream.
gcc/
* asan.h
4fa59 Mon Sep 17 00:00:00 2001
From: Maxim Ostapenko
Date: Tue, 25 Oct 2016 20:34:23 +0300
Subject: [PATCH 5/7] libsanitizer merge from upstream r285547, compiler part.
gcc/
* asan.h (ASAN_STACK_MAGIC_PARTIAL): Remove.
* asan.c (ASAN_STACK_MAGIC_PARTIAL): Replace with
ASAN_STACK_MAGIC_M
avoid this, this patch removes
CheckODRViolationViaPoisoning call and leaves only
CheckODRViolationViaIndicator.
From 5cd9a7cb1c2dd668e533bee1bc15e367d367d84f Mon Sep 17 00:00:00 2001
From: Maxim Ostapenko
Date: Fri, 28 Oct 2016 10:22:35 +0300
Subject: [PATCH 4/7] libsanitizer/
* asan/asan_
This patch adjusts the fix for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61771 to extract the last
PC from the stack frame if no valid FP is available for ARM.
From 6dc6e4f761080cf19a161fb0e27c1fd584688f40 Mon Sep 17 00:00:00 2001
From: Maxim Ostapenko
Date: Tue, 25 Oct 2016 20:27:37 +0300
This is just reapplied patch for SPARC by David S. Miller.
From 0ff8d1c408b076970c323361922c35033aaae245 Mon Sep 17 00:00:00 2001
From: Maxim Ostapenko
Date: Tue, 25 Oct 2016 20:00:43 +0300
Subject: [PATCH 2/7] libsanitizer/
PR sanitizer/63958
Reapply:
2014-10-14 David S. Miller
Hi,
this patch set performs libsanitizer merge from upstream.
Patch 1 is the library merge itself.
Patch 2 is the reapplied change for SPARC by David S. Miller.
Patch 3 changes heuristic for extracting last PC from stack frame for
ARM in fast unwind routine. More details can be found here
(h
On 10/06/16 14:41, Maxim Ostapenko wrote:
On 10/06/16 14:18, Jakub Jelinek wrote:
On Fri, Jun 10, 2016 at 02:12:37PM +0300, Maxim Ostapenko wrote:
gcc/ChangeLog:
2016-06-10 Maxim Ostapenko
PR sanitizer/71480
* varasm.c (place_block_symbol): Adjust alignment for asan
protected
On 10/06/16 14:18, Jakub Jelinek wrote:
On Fri, Jun 10, 2016 at 02:12:37PM +0300, Maxim Ostapenko wrote:
gcc/ChangeLog:
2016-06-10 Maxim Ostapenko
PR sanitizer/71480
* varasm.c (place_block_symbol): Adjust alignment for asan protected
STRING_CSTs even if
ux-gnueabi (I didn't
manage to test on PowerPC), ok for trunk?
-Maxim
gcc/ChangeLog:
2016-06-10 Maxim Ostapenko
PR sanitizer/71480
* varasm.c (place_block_symbol): Adjust alignment for asan protected
STRING_CSTs even if TREE_CONSTANT_POOL_ADDRESS_P.
gcc/testsuite/ChangeLog:
20
On 18/05/16 20:36, Jakub Jelinek wrote:
On Wed, May 18, 2016 at 08:33:53PM +0300, Maxim Ostapenko wrote:
when compiling with -fsanitize=address we define __SANITIZE_ADDRESS__
macros, but we don't do this for -fsanitize=thread and -fsanitize=undefined.
Perhaps we should be more symmetric
On 18/05/16 20:39, Yuri Gribov wrote:
On Wed, May 18, 2016 at 8:33 PM, Maxim Ostapenko
wrote:
Hi,
when compiling with -fsanitize=address we define __SANITIZE_ADDRESS__
macros, but we don't do this for -fsanitize=thread and -fsanitize=undefined.
Perhaps we should be more symmetric her
?
I added two simple test cases to c-c++-common/{ub, t}san/ directories
that just verify if __SANITIZE_THREAD__ (__SANITIZE_UNDEFINED__) is
defined. Is that a proper way how we check that the macros defined
correctly? Does this patch looks reasonable?
-Maxim
gcc/ChangeLog:
2016-05-19 Maxim Osta
Hi Jakub,
thanks for backporting this! Do you have any plans to apply this patch
to GCC 5 and 6 branches? AFAIK people hit on this ASan + newer Glibc bug
by using GCC 5.3.1 on Fedora 23.
On 17/05/16 12:23, Jakub Jelinek wrote:
Hi!
This is a cherry-pick of upstream fix, so that dlsym can cal
ling out if &dyldVersionNumber == 0.
Tested by Dominique on x86_64-apple-darwin10 and x86_64-apple-darwin15
(see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70624#c8).
Ok for mainline? If yes, should I back port this patch to gcc-{4.9, 5,
6}-branch?
-Maxim
libsanitizer/ChangeLog:
2016-04-21
On 08/04/16 12:12, Jakub Jelinek wrote:
On Fri, Apr 08, 2016 at 11:52:32AM +0300, Maxim Ostapenko wrote:
2016-04-08 Maxim Ostapenko
PR sanitizer/70541
* asan.c (instrument_derefs): If we get unknown location, extract it
with EXPR_LOCATION
ss in
initialize_inlined_parameters routine.
Regtested and bootstrapped on x86_64-unknown-linux-gnu, OK to commit?
-Maxim
gcc/ChangeLog:
2016-04-08 Maxim Ostapenko
PR sanitizer/70541
* asan.c (instrument_derefs): If we get unknown location, extract it
with EXPR_LOCATION.
(maybe_instrument
for gcc-4_9-branch?
-Maxim
libsanitizer/ChangeLog:
2016-04-05 Maxim Ostapenko
PR sanitizer/70474
* asan/asan_mac.cc (GetMacosVersionInternal): Cherry pick
upstream r241487, 221379 and r224315.
(void MaybeReexec): Cherry pick upstream r241487.
* asan/asan_mac.h (enum MacosVersion): Cherry
On 02/03/16 16:59, Ian Lance Taylor wrote:
On Wed, Mar 2, 2016 at 12:51 AM, Maxim Ostapenko
wrote:
When testing ASan on large system, I've noticed that sometimes it crashes
with SEGV in Libbacktrace when trying to symbolize stripped PIE (compiled
with -pie -fPIC) binaries in fully str
ueabi, OK for trunk?
-Maxim
libbacktrace/ChangeLog:
2016-03-02 Maxim Ostapenko
* elf.c (backtrace_initialize): Properly initialize elf_fileline_fn to
avoid possible crash.
diff --git a/libbacktrace/elf.c b/libbacktrace/elf.c
index 05cc5c0..c7168c6 100644
--- a/libbacktrace/elf.c
+++ b/libbacktr
86_64-apple-darwin15.2.0 by Dominique
(https://gcc.gnu.org/ml/gcc-testresults/2016-01/msg01115.html).
Ok for gcc-5-branch?
-Maxim
libsanitizer/ChangeLog:
2016-01-13 Maxim Ostapenko
* PR sanitizer/69147
* asan/asan_mac.cc: Cherry pick upstream r241487.
* sanitizer_common/sanitizer_mac.cc: C
On 01/12/15 20:23, Maxim Ostapenko wrote:
On 25/11/15 12:14, Maxim Ostapenko wrote:
I would like to ping the patch:
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02174.html.
Ping.
Ping.
-Maxim
On 25/11/15 12:14, Maxim Ostapenko wrote:
I would like to ping the patch:
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02174.html.
Ping.
-Maxim
I would like to ping the patch:
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02174.html.
On 24/11/15 15:17, Christophe Lyon wrote:
On 24 November 2015 at 12:57, Jakub Jelinek wrote:
On Tue, Nov 24, 2015 at 02:55:26PM +0300, Maxim Ostapenko wrote:
diff --git a/libsanitizer/ChangeLog b/libsanitizer/ChangeLog
index c392c57..895d3bd 100644
--- a/libsanitizer/ChangeLog
+++ b
geLog
index c392c57..895d3bd 100644
--- a/libsanitizer/ChangeLog
+++ b/libsanitizer/ChangeLog
@@ -1,5 +1,10 @@
2015-11-24 Maxim Ostapenko
+ * include/system/linux/asm/ptrace.h: Move to ...
+ * include/system/asm/ptrace.h: ... this.
+
+2015-11-24 Maxim Ostapenko
+
* include/system/linux/a
On 24/11/15 11:38, Jakub Jelinek wrote:
On Tue, Nov 24, 2015 at 11:36:20AM +0300, Maxim Ostapenko wrote:
Ok, does it look better now?
Sure, this is ok for trunk.
diff --git a/libsanitizer/ChangeLog b/libsanitizer/ChangeLog
index b97fc7d..c392c57 100644
--- a/libsanitizer/ChangeLog
+++ b
On 24/11/15 11:25, Jakub Jelinek wrote:
On Tue, Nov 24, 2015 at 10:51:05AM +0300, Maxim Ostapenko wrote:
Ok, I posted a fix to upstream (http://reviews.llvm.org/D14921) yesterday,
but it's still not reviewed. So, I'm wondering if I should fix the issue
locally?
Attaching proposed fix
On 23/11/15 16:24, Jakub Jelinek wrote:
On Mon, Nov 23, 2015 at 04:21:34PM +0300, Maxim Ostapenko wrote:
Yeah, right. I've asked about kernel headers just to make sure I correctly
understand the issue.
Actually, I see such code in
lib/sanitizer_common/sanitizer_platform_limits_posix.cc:
On 23/11/15 16:00, Christophe Lyon wrote:
On 23 November 2015 at 13:41, Jakub Jelinek wrote:
On Mon, Nov 23, 2015 at 03:33:57PM +0300, Maxim Ostapenko wrote:
+ Adhemerval
Christophe, it looks like your kernel headers (asm/ptrace.h) don't contain
ARM_VFPREGS_SIZE. Do you use old k
+ Adhemerval
Christophe, it looks like your kernel headers (asm/ptrace.h) don't
contain ARM_VFPREGS_SIZE. Do you use old kernel version?
-Maxim
On 23/11/15 15:16, Christophe Lyon wrote:
On 23 November 2015 at 09:07, Jakub Jelinek wrote:
On Mon, Nov 23, 2015 at 10:46:33AM +0300,
15-11-23 Maxim Ostapenko
* c-c++-common/asan/halt_on_error-1.c: New test.
* c-c++-common/asan/halt_on_error-2.c: Likewise.
gcc/ChangeLog:
2015-11-23 Maxim Ostapenko
* opts.c (finish_options): Allow -fsanitize-recover=address for
userspace sanitization.
* asan.c (asan_expand_chec
Hi!
Following recent discussion
(https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02310.html), I would like
to merge recent sanitizer library to GCC to make available new useful
features from upstream in GCC 6:
* The shadow offset for ASan was unified on Aarch64 for 39 and 42 VMAs
(http://revi
On 19/11/15 13:18, Jakub Jelinek wrote:
On Thu, Nov 19, 2015 at 11:19:23AM +0300, Maxim Ostapenko wrote:
Hi!
Since the last sanitizer library merge to GCC happened, some new useful
features were applied upstream. In particular, the most significant are:
* The shadow offset for ASan was
Hi!
Since the last sanitizer library merge to GCC happened, some new useful
features were applied upstream. In particular, the most significant are:
* The shadow offset for ASan was unified on Aarch64 for 39 and 42 VMAs
(http://reviews.llvm.org/D13782). AFAU, this change wouldn't require any
Hi,
this small patch fixes the logic in ASan vs SSP interaction to provide
correct "size" parameter to asan_stack_malloc_[N] routines. With current
logic, we would have assertion failure in libsanitizer in UAR mode on
32-bit targets due to wrong granularity of resulting addr + size address.
.
Regtested and bootstrapped on x86_64-unknown-linux-gnu, OK to apply?
-Maxim
gcc/ChangeLog:
2015-10-28 Maxim Ostapenko
* asan.h (asan_intercepted_p): Handle BUILT_IN_STRCSPN,
BUILT_IN_STRPBRK, BUILT_IN_STRSPN and BUILT_IN_STRSTR.
gcc/testsuite/ChangeLog:
2015-10-28 Maxim Ostapenko
* c-c
1 - 100 of 227 matches
Mail list logo
