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
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
>
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
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
> Instead of mentioning the directory in the ChangeLog,
> mention the individual test files.
> ...
>* g++.dg/dg.exp: Prune tsan subdirectory.
Thanks, I fixed the ChangeLog file.
> how long does it take to run make check-gcc check-g++
RUNTESTFLAGS=tsan.exp ?
> How much memory does it need?
> 2013-12-05 Max Ostapenko < m.ostape...@partner.samsung.com >
> 2013-12-05 Max Ostapenko actually.
Ok, I'm sorry, I'll fix it. Ok to commit?
-Maxim
2013-12-05 Max Ostapenko
* c-c++-common/tsan/atomic_stack.c: New test.
* c-c++-common/tsan/fd_pipe_race.c: New test.
Hello,
From http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410#c1 issue:
> BTW, the tsan.exp tests don't seem to be as cheap as was claimed
during the patch
> submission, I'd prefer to at least throttle the > torture options
down to say -O0
> and -O2 rather than so many different variants when
Hi all,
I've added new tests for tsan from LLVM.
Tested on x86_64.
Ok to commit?
-Maxim
diff --git a/gcc/testsuite/c-c++-common/tsan/free_race2.c b/gcc/testsuite/c-c++-common/tsan/free_race2.c
new file mode 100644
index 000..3c15d2d
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/tsan/free
> Anyway, let's keep the current tests as is, the patch is ok for trunk.
Commited in 205925.
Hi all,
On 12/06/2013 05:32 PM, Yury Gribov wrote:
So it looks like people are generally ok with
* --param asan-instrument-reads=0/1
* --param asan-instrument-writes=0/1
* --param asan-stack=0/1
* --param asan-globals=0/1
I've implemented these options. Tested on x86_64.
* --param asan-memint
2013-12-18 Max Ostapenko
* gcc/asan.c (asan_emit_stack_protection): Optionally disable
stack protection.
(instrument_derefs): Optionally disable memory access
instrumentation.
(instrument_mem_region_access): Likewise.
(instrument_strlen_call): Likewise.
(asan_finish_file)
Sorry, ChangeLog and patch, of course.
-Maxim.
2013-12-19 Max Ostapenko
* cfgexpand.c (expand_stack_vars): Optionally disable asan stack protection.
(expand_used_vars): Likewise.
(partition_stack_vars): Likewise.
* asan.c (asan_emit_stack_protection): Optionally disable after return stack
On 12/19/2013 04:27 PM, Jakub Jelinek wrote:
On Thu, Dec 19, 2013 at 04:02:47PM +0400, Maxim Ostapenko wrote:
Sorry, ChangeLog and patch, of course.
2013-12-19 Max Ostapenko
* cfgexpand.c (expand_stack_vars): Optionally disable asan stack
protection.
Too long lines in ChangeLog
Hi!
>> * c-c++-common/asan/no-asan-stack.c (this triggers read overflow
>> because we haven't found a cross-platform way to grep for stack
>> redzones instrumentation)
> I'd prefer no test in that case, or just some semi-platform specific
test
> (scan that the 0x41b58ab3 constant doesn't appear
Hi!
>>> * c-c++-common/asan/no-asan-stack.c (this triggers read overflow
>>> because we haven't found a cross-platform way to grep for stack
>>> redzones instrumentation)
>>
>> I'd prefer no test in that case, or just some semi-platform specific
test
>> (scan that the 0x41b58ab3 constant doesn't
If you want to limit to x86_64-linux only, please do:
target { { i?86-*-linux* x86_64-*-linux* } && lp64 }
instead. Also, what advantages do you see for trying to assemble
the result? If you instead just do dg-do compile, you can drop -save-temps
from dg-options and /* { dg-final { cleanup-saved
On 01/10/2014 12:36 PM, Jakub Jelinek wrote:
On Fri, Jan 10, 2014 at 12:34:49PM +0400, Maxim Ostapenko wrote:
Thanks, got it. Is it OK now?
Yes, thanks.
2014-01-10 Max Ostapenko
* c-c++-common/asan/no-asan-stack.c: New test.
Jakub
Commited in 206515.
-Maxim.
Hi all,
On Fri, Jan 10, 2014 at 10:39 AM, Jakub Jelinek wrote:
> Some of the tsan tests seems to FAIL randomly for quite a while
> (since they were added), didn't have time to look if it is just bugs
in the test or
> some compiler issue or library issue.
When I've commited these tsan tests,
discussed.
Here a draft patch that disables -fprofile-use related optimizations if
profile data wasn't found (perhaps it makes sense to introduce a special
switch for this?). Does this look reasonable?
Thanks,
-Maxim
gcc/ChangeLog:
2015-10-07 Maxim Ostapenko
* coverage.c (disable_pr
On 07/10/15 19:18, Andrew Pinski wrote:
On Wed, Oct 7, 2015 at 9:11 AM, Maxim Ostapenko
wrote:
Hi,
when testing OpenSSL performance, I found out that sometimes PGO-built
binaries can actually introduce performance regressions. We could identify
affected object files and disable PGO for them
d, although I see some errors
detected (will report them later).
Is this OK for trunk?
-Maxim
gcc/fortran/ChangeLog:
2015-10-08 Maxim Ostapenko
* parse.c (decode_statement): Initialize M to MATCH_NO.
diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c
index 6f3d24b..4925c7e 100644
---
Hi,
it's been a while since the last libsanitizer merge from upstream into
GCC happened and the library has significantly changed since that time.
The main features to be ported are:
-New common strings interceptors were added.
-Various allocator improvements were performed.
-Improvements for
This patch introduces required compiler changes. Now, we don't version
asan_init, we have a special __asan_version_mismatch_check_v[n] symbol
for this.
Also, asan_stack_malloc_[n] doesn't take a local stack as a second
parameter anymore, so don't pass it.
2015-10-12 Maxim Osta
This is just reapplied patch for SPARC by David S. Miller. I was unable
to test this, so could anyone help me here?
2015-10-12 Maxim Ostapenko
PR sanitizer/63958
Reapply:
2015-03-09 Jakub Jelinek
PR sanitizer/63958
Reapply:
2014-10-14 David S. Miller
* sanitizer_common
This is a reapplied Jakub's patch for disabling ODR violation detection.
More details can be found here
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888).
2015-10-12 Maxim Ostapenko
PR bootstrap/63888
Reapply:
2015-02-20 Jakub Jelinek
* asan/asan_globals.cc (RegisterG
ut of scope of this merge.
2015-10-13 Maxim Ostapenko
* tsan/tsan_defs.h: Define TSAN_CONTAINS_UBSAN to 0.
* asan/asan_flags.cc (InitializeFlags): Do not initialize UBSan flags.
* asan/asan_rtl.cc (AsanInitInternal): Do not init UBSan.
Index: libsanitizer/asan/asan_fla
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.
2015-10-13 Maxim Ostapenko
* sanitizer_common/sanitizer_stacktrace.cc (GetCanonicFrame): Assume we
compiled code with GCC when
This is the final patch. Force libsanitizer to use an old ABI for ubsan
float cast data descriptors, because for some exprs (e.g. that type of
tcc_declaration) we can't get the right location for now. I'm not sure
about this, perhaps it should be fixed in GCC somehow.
2015-10
On 14/10/15 10:54, Jakub Jelinek wrote:
On Tue, Oct 13, 2015 at 07:54:33PM +0300, Maxim Ostapenko wrote:
On 13/10/15 14:15, Maxim Ostapenko wrote:
This is the raw merge itself. I'm bumping SONAME to libasan.so.3.
-Maxim
I have just noticed that I've misused autoconf stuff (used wro
On 14/10/15 10:48, Jakub Jelinek wrote:
On Tue, Oct 13, 2015 at 02:22:36PM +0300, Maxim Ostapenko wrote:
This is the final patch. Force libsanitizer to use an old ABI for ubsan
float cast data descriptors, because for some exprs (e.g. that type of
tcc_declaration) we can't get the
On 14/10/15 14:06, Jakub Jelinek wrote:
On Wed, Oct 14, 2015 at 01:51:44PM +0300, Maxim Ostapenko wrote:
Ok, got it. The first solution would require changes in libsanitizer because
heuristic doesn't work for GCC, so perhaps new UBSan entry point should go
upstream, right? Or this m
On 14/10/15 10:37, Jakub Jelinek wrote:
On Tue, Oct 13, 2015 at 02:20:06PM +0300, Maxim Ostapenko wrote:
This patch removes UBSan stubs from ASan and TSan code. We don't embed UBSan
to ASan and UBSan because that would lead to undefined references to C++
stuff when linking with -static-li
On 14/10/15 10:30, Jakub Jelinek wrote:
On Tue, Oct 13, 2015 at 02:16:23PM +0300, Maxim Ostapenko wrote:
This patch introduces required compiler changes. Now, we don't version
asan_init, we have a special __asan_version_mismatch_check_v[n] symbol for
this.
For this, I just have to wonder
On 14/10/15 15:12, Jakub Jelinek wrote:
On Wed, Oct 14, 2015 at 03:02:22PM +0300, Maxim Ostapenko wrote:
On 14/10/15 14:06, Jakub Jelinek wrote:
On Wed, Oct 14, 2015 at 01:51:44PM +0300, Maxim Ostapenko wrote:
Ok, got it. The first solution would require changes in libsanitizer because
On 16/10/15 16:48, Renato Golin wrote:
On 14 October 2015 at 19:38, Renato Golin wrote:
On 14 October 2015 at 19:21, Evgenii Stepanov wrote:
Wait. As Jakub correctly pointed out in the other thread, there is no
obvious reason why there could not be a single shadow offset value
that would work
Hi,
this is the second attempt to perform libsanitizer merge from upstream.
In previous patch set (
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01212.html) we have
revealed an issue with heuristic for old/new style ubsan_data that was
needed to be fixed upstream + some errors in compiler ch
float_cast
was adjusted to pass source location for libubsan if it is possible.
gcc/ChangeLog:
2015-10-20 Maxim Ostapenko
gcc/
* asan.c (asan_emit_stack_protection): Don't pass local stack to
asan_stack_malloc_[n] anymore. Check if asan_stack_malloc_[n] returned
NULL and use local stack than
This is just reapplied patch for SPARC by David S. Miller. The patch was
preapproved here:
(https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01214.html).
2015-10-20 Maxim Ostapenko
PR sanitizer/63958
Reapply:
2014-10-14 David S. Miller
* sanitizer_common
This is a reapplied Jakub's patch for disabling ODR violation detection.
The patch was preapproved here:
(https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01215.html).
2015-10-20 Maxim Ostapenko
PR bootstrap/63888
Reapply:
2015-02-20 Jakub Jelinek
* asan/asan_globals.cc (RegisterG
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. The patch
was preapproved here:
(https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01217.html).
2015-10-20 Maxim Ostapenko
In this patch, I'm trying to add a general instruction how to perform
the merge. This is just a documentation patch, any suggestions and
opinions are welcome.
Index: libsanitizer/HOWTO_MERGE
===
--- libsanitizer/HOWTO_MERGE (revision
Great, thanks! I'm going to commit the whole patch set tomorrow morning
if no objections.
On 20/10/15 14:52, Jakub Jelinek wrote:
On Tue, Oct 20, 2015 at 02:18:25PM +0300, Maxim Ostapenko wrote:
This is the merge itself. Added DCAN_SANITIZE_UB={0, 1} and
-linux-gnu, how does it look?
-Maxim
libsanitizer/ChangeLog:
2015-10-21 Maxim Ostapenko
PR bootstrap/68041
* configure.ac (link_sanitizer_common): Link against librt only if it
contains shm_open, required by sanitizers.
(CXX_ABI_NEEDED): Remove variable.
* configure: Regenerate.
* ub
apply?
-Maxim
gcc/testsuite/ChangeLog:
2015-10-22 Maxim Ostapenko
PR sanitizer/68042
* c-c++-common/asan/memcmp-1.c: Adjust test to pass on Darwin.
* c-c++-common/asan/sanity-check-pure-c-1.c: Likewise.
Index: gcc/testsuite/c-c++-common/asan/memcmp-1.c
This patch updates libsanitizer/HOWTO_MERGE file according to Yura's
nits here: https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02039.html.
Just a documentation patch, no changes in functionality.
-Maxim
Index: libsanitizer/HOWTO_MERGE
=
ommon
command line options are parsed). If .gcda file exists, enable
PGO-related optimizations and emit warning otherwise. I believe this
should not break existing code.
Regtested and bootstrapped on x86_64-unknown-linux-gnu.
Does the patch look sensible?
Thanks,
-Maxim
gcc/ChangeLog:
2015-10-27
already for a
number of other cases. So, probably the right thing to do.
You might want to coordinate with Maxim ostapenko who's currently
working on another -fprofile-use patch. Hopefully not one that
disables -freorder-blocks-and-partition if it can't find .gcda files.
AFAU,
.
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
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.
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
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!
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
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
+ 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,
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
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 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 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
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 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
I would like to ping the patch:
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02174.html.
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
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
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 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
raden Obrzut
Carlos O'Donell
Peter O'Gorman
Andrea Ornstein
+Maxim Ostapenko
Patrick Palka
Devang Patel
Andris Pavenis
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
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
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
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 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,
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
(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
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
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
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
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
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
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 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
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
Ping.
-Maxim
Original Message
Subject:[PATCH] Add patch for debugging compiler ICEs.
Date: Mon, 04 Aug 2014 21:03:22 +0400
From: Maxim Ostapenko
To: GCC Patches
CC: Jeff Law , Jakub Jelinek ,
tsaund...@mozilla.com, Yury Gribov , Slava
Garbuzov
On 08/04
Ping.
-Maxim
Original Message
Subject:[PATCH] Add patch for debugging compiler ICEs.
Date: Mon, 04 Aug 2014 21:03:22 +0400
From: Maxim Ostapenko
To: GCC Patches
CC: Jeff Law , Jakub Jelinek ,
tsaund...@mozilla.com, Yury Gribov , Slava
Garbuzov
Hi,
A
Hi,
When testing, I've noticed, that Asan-bootstrapped GCC should be
executed with ASAN_OPTIONS=detect_leaks=0 because of memory leaks in
GCC, reported by Leak Sanitizer.
When I ran Asan test on Asan-bootstrapped GCC, some of them fail with
memory leaks into GCC, even if Lsan is disabled. Th
Hi,
When I ran Asan tests under Asan-bootstrapped GCC 5.0, I've noted, that
tests for libiberty and libbacktrace fail to link with sanitized
libbacktrace.a and libiberty.a because of missing -static-libasan
-fsanitize=address linker flags.
This patch adds necessary flags to provide a linkage
Ping. Add Joseph S. Myers as driver maintainer.
-Maxim
Original Message
Subject:Fwd: [PATCH] Add patch for debugging compiler ICEs.
Date: Tue, 19 Aug 2014 17:57:51 +0400
From: Maxim Ostapenko
To: Jeff Law , GCC Patches
CC: tsaund...@mozilla.com, Yury Gribov
On 08/25/2014 07:21 PM, Bernhard Reutner-Fischer wrote:
On 25 August 2014 16:23:54 CEST, Yury Gribov wrote:
On 08/25/2014 11:04 AM, Maxim Ostapenko wrote:
This patch adds necessary flags to provide a linkage of these tests
in
bootstrap-asan case.
I think you'll want to modify Makefil
On 09/01/2014 11:29 AM, Jakub Jelinek wrote:
On Mon, Sep 01, 2014 at 11:19:07AM +0400, Maxim Ostapenko wrote:
libiberty/ChangeLog:
2014-09-01 Max Ostapenko
* testsuite/Makefile.in(LIBCFLAGS): Add LDFLAGS.
Space before (.
Ugh, sorry.
# Flags to pass down to makes which are
Ping.
-Maxim
Original Message
Subject:[PATCH] Fix environment variables restoring in GCC testsuite.
Date: Fri, 22 Aug 2014 14:39:16 +0400
From: Maxim Ostapenko
To: GCC Patches
CC: Yury Gribov , Slava Garbuzov
Hi,
When testing, I've noticed, that
Ping.
-Maxim
On 08/28/2014 11:31 AM, Maxim Ostapenko wrote:
Ping. Add Joseph S. Myers as driver maintainer.
-Maxim
Original Message
Subject: Fwd: [PATCH] Add patch for debugging compiler ICEs.
Date: Tue, 19 Aug 2014 17:57:51 +0400
From: Maxim Ostapenko
To
Ping.
Original Message
Subject: Re: [PATCH] Fix libbacktrace and libiberty tests fail on
sanitized GCC due to wrong link options.
Date: Mon, 01 Sep 2014 12:33:09 +0400
From: Maxim Ostapenko
To: Jakub Jelinek
CC: Bernhard Reutner-Fischer , Yury Gribov
, GCC
context correctly.
What solution is preferable?
-Maxim
On 10/08/2014 01:02 PM, Marcus Shawcroft wrote:
On 1 October 2014 08:09, Maxim Ostapenko
wrote:
Hi,
some time ago, Andrew wrote a patch that fixes PR58867
(http://patchwork.ozlabs.org/patch/286866/), but for some reasons it
wasn&#
wrote:
On 8 October 2014 11:10, Maxim Ostapenko
wrote:
Does it work without restore_ld_library_path in {asan, ubsan, tsan}_finish?
I see two opportunities to fix the issue:
1) Implement a stack of saved contexts.
2) Implement new functions, say {asan, ubsan, tsan}_restore_ld_library_path,
to be
Hi Jiong,
I couldn't reproduce tests failures on my box, perhaps I missed
something. How can I test this?
-Maxim
On 10/08/2014 06:30 PM, Jiong Wang wrote:
On 08/10/14 15:00, Maxim Ostapenko wrote:
Hm, as I see, others testsuites such as gfortran.exp, go.exp etc. do not
Hi,
After enabling ASan, TSan and UBSan testsuites for installed toolchain,
many tests started to fail. This is caused by wrong logic in {asan,
ubsan, tsan}_finish
functions. Here, restore_ld_library_path is called, that is wrong,
because it drops some env variables ( GCC_EXEC_PREFIX, LD_LIBRA
Adding Jakub.
-Maxim
On 10/09/2014 04:34 PM, Maxim Ostapenko wrote:
Hi,
After enabling ASan, TSan and UBSan testsuites for installed
toolchain, many tests started to fail. This is caused by wrong logic
in {asan, ubsan, tsan}_finish
functions. Here, restore_ld_library_path is called, that is
On 10/10/2014 11:30 AM, Jakub Jelinek wrote:
On Fri, Oct 10, 2014 at 11:13:11AM +0400, Maxim Ostapenko wrote:
Adding Jakub.
-Maxim
On 10/09/2014 04:34 PM, Maxim Ostapenko wrote:
Hi,
After enabling ASan, TSan and UBSan testsuites for installed toolchain,
many tests started to fail. This is
Hi,
this patch disables string/memory builtin functions inlining if ASan is
enabled. As described in my previous post
(https://gcc.gnu.org/ml/gcc/2014-09/msg00020.html), this allow us to be
sure that some dangerous builtins (strcpy, stpcpy, etc) will be handled
correctly. Also, some redundant
Hi,
this is the second version of the patch. Here the major changes from the
previous one:
1) Added a new intercepted_p parameter in get_mem_refs_of_builtin_call
to decide whether builtin function should/shouldn't be instrumented.
2) Changed instrument_mem_region_access function. Now, we up
On 10/24/2014 02:43 PM, Eric Botcazou wrote:
some time ago, Andrew wrote a patch that fixes PR58867
(http://patchwork.ozlabs.org/patch/286866/), but for some reasons it
wasn't committed to trunk.
This is resurrected Andrew's patch, extended to support Tsan testsuite.
This patch broke --disable
1 - 100 of 227 matches
Mail list logo
