Pushed with LOCAL_PATCHES update :)
On Fri, Nov 8, 2024 at 7:40 PM Jakub Jelinek wrote:
>
> On Fri, Nov 08, 2024 at 07:38:13PM +0800, Xi Ruoyao wrote:
> > IIUC 4/4 shouldn't be in LOCAL_PATCHES? It modifies our own test case,
> > not from the upstream.
>
> Sure, sorry.
>
> Jakub
>
On Fri, Nov 08, 2024 at 07:38:13PM +0800, Xi Ruoyao wrote:
> IIUC 4/4 shouldn't be in LOCAL_PATCHES? It modifies our own test case,
> not from the upstream.
Sure, sorry.
Jakub
but I received warnings from
> > LeakSanitizer due to the pretty printer, which make the test results
> > unusable...
>
> If pretty-printer now massively leaks, we should file a PR and get it fixed
> for GCC 15.
>
> > Kito Cheng (4):
> > libsanitizer: merge from u
massively leaks, we should file a PR and get it fixed
for GCC 15.
> Kito Cheng (4):
> libsanitizer: merge from upstream (61a6439f35b6de28)
> libsanitizer: Apply local patches
> libsanitizer: Improve FrameIsInternal
> libsanitizer: update test
Ok for trunk, but please mention
Kito Cheng writes:
> The patch set aims to update libsanitizer from upstream. The motivation is
> that
> RISC-V is changing the shadow offset for AddressSanitizer, and I also plan to
> submit another patch set to add dynamic shadow offset support for GCC.
>
> This is my first time updating it, s
-config=bootstrap-asan, but I received warnings from
LeakSanitizer due to the pretty printer, which make the test results
unusable...
Kito Cheng (4):
libsanitizer: merge from upstream (61a6439f35b6de28)
libsanitizer: Apply local patches
libsanitizer: Improve FrameIsInternal
libsanitizer
> I see that the fix was applied locally (and my bootstraps on various Darwin
> versions worked OK),
> but I’m not clear if you submitted a PR upstream (or just the bug report).
> If the fix is to remain
> local-only, it should be added to the list in LOCAL_PATCHES.
Patch was submitted upstre
Hi FX
> On 17 Nov 2023, at 11:57, FX Coudert wrote:
>
>> If they accept it say within a day, wait for it + cherry-pick to GCC,
>> otherwise apply to GCC as a local patch in anticipation they accept it.
>> If it is all that fixes Darwin support, great.
>
> With that patch, I can finish bootstrap
> If they accept it say within a day, wait for it + cherry-pick to GCC,
> otherwise apply to GCC as a local patch in anticipation they accept it.
> If it is all that fixes Darwin support, great.
With that patch, I can finish bootstrap, and regtesting is undergoing but I’m
seeing no issue so far.
On Fri, Nov 17, 2023 at 12:31:40PM +0100, FX Coudert wrote:
> I have reported the issue to llvm at
> https://github.com/llvm/llvm-project/issues/72639
> There is a trivial one-line patch to fix it, which I hope they will accept.
> Not sure what our policy is here, in the meantime.
If they accept
I have reported the issue to llvm at
https://github.com/llvm/llvm-project/issues/72639
There is a trivial one-line patch to fix it, which I hope they will accept. Not
sure what our policy is here, in the meantime.
FX
Heads-up: this broke bootstrap on darwin:
> +typedef void (^dispatch_mach_handler_t)(dispatch_mach_reason reason,
> +dispatch_mach_msg_t message,
> +mach_error_t error);
Blocks are an Apple/clang extension, not (yet)
On Wed, 15 Nov 2023, Jakub Jelinek wrote:
> Hi!
>
> The following patch is result of libsanitizer/merge.sh
> from c425db2eb558c263 (yesterday evening).
>
> Bootstrapped/regtested on x86_64-linux and i686-linux (together with
> the follow-up 3 patches I'm about to post).
>
> Iain, could you plea
Jakub Jelinek writes:
> Hi!
>
> The following patch is result of libsanitizer/merge.sh
> from c425db2eb558c263 (yesterday evening).
>
> Bootstrapped/regtested on x86_64-linux and i686-linux (together with
> the follow-up 3 patches I'm about to post).
>
> Iain, could you please check Darwin?
>
>
Hi Martin,
> On 9/4/22 21:50, Iain Sandoe wrote:
>> Hi Martin,
>>
>>> On 30 Aug 2022, at 11:53, Martin Liška wrote:
>>>
>>> On 5/4/22 10:59, Martin Liška wrote:
Hello.
>>> I've just done one more merge from upstream.
>>> Upstream revision: 84a71d5259c2682403cdbd8710592410a2f128ab.
>>
>> Wh
On 9/4/22 21:50, Iain Sandoe wrote:
> Hi Martin,
>
>> On 30 Aug 2022, at 11:53, Martin Liška wrote:
>>
>> On 5/4/22 10:59, Martin Liška wrote:
>>> Hello.
>> I've just done one more merge from upstream.
>> Upstream revision: 84a71d5259c2682403cdbd8710592410a2f128ab.
>
> Which (again) breaks boots
Hi Martin,
> On 30 Aug 2022, at 11:53, Martin Liška wrote:
>
> On 5/4/22 10:59, Martin Liška wrote:
>> Hello.
> I've just done one more merge from upstream.
> Upstream revision: 84a71d5259c2682403cdbd8710592410a2f128ab.
Which (again) breaks bootstrap on Darwin (since upstream uses features
and
On 5/4/22 10:59, Martin Liška wrote:
> Hello.
>
> I'm going to do merge from upstream.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests. I've
> also tested
> on ppc64le-linux-gnu and verified the ABI.
>
> The only real change is a small change in
> gcc/testsuite/c-c++-c
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 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 heuri
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 thi
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 __in
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 __interceptor_lstat{64}
>> wer
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 think we need to readd those and perh
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
On Mon, Nov 07, 2016 at 11:31:18AM +0300, Maxim Ostapenko wrote:
> --- a/gcc/asan.c
> +++ b/gcc/asan.c
> @@ -1329,6 +1329,16 @@ asan_needs_local_alias (tree decl)
>return DECL_WEAK (decl) || !targetm.binds_local_p (decl);
> }
>
> +/* Return true if DECL, a global var, is an artificial ODR in
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 for extracti
This patch tries to implement odr indicators functionality at compiler
side.
We emit new __odr_asan_XXX symbol for each instrumented global that
indicates whether this global was already registered and the library
checks this indicator symbol at runtime. For some globals (e.g. static
or hidden)
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 (asan_intercepted
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
This is rewritten Jakub's fix for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888. Upstream now
supports new approach for ODR violation detection: compiler emits new
__odr_asan_XXX symbol for each instrumented global that indicates
whether this global was already registered and the library c
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
Su
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
* saniti
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
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/libsanitiz
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/libsanitizer/ChangeLog
>> @@ -1,5 +1,10 @@
On 11/24/2015 02:55 PM, Maxim Ostapenko wrote:
On 24/11/15 14:27, Jakub Jelinek wrote:
On Tue, Nov 24, 2015 at 12:23:05PM +0100, Christophe Lyon wrote:
On 24 November 2015 at 12:12, Jakub Jelinek wrote:
On Tue, Nov 24, 2015 at 12:08:13PM +0100, Christophe Lyon wrote:
Sure.
I had a build in p
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/libsanitizer/ChangeLog
> @@ -1,5 +1,10 @@
> 2015-11-24 Maxim Ostapenko
>
> + * include/sys
On 24/11/15 14:27, Jakub Jelinek wrote:
On Tue, Nov 24, 2015 at 12:23:05PM +0100, Christophe Lyon wrote:
On 24 November 2015 at 12:12, Jakub Jelinek wrote:
On Tue, Nov 24, 2015 at 12:08:13PM +0100, Christophe Lyon wrote:
Sure.
I had a build in progress with your proposed patch, but it didn't
On Tue, Nov 24, 2015 at 12:23:05PM +0100, Christophe Lyon wrote:
> On 24 November 2015 at 12:12, Jakub Jelinek wrote:
> > On Tue, Nov 24, 2015 at 12:08:13PM +0100, Christophe Lyon wrote:
> >> > Sure.
> >> > I had a build in progress with your proposed patch, but it didn't
> >> > complete before yo
On 24 November 2015 at 12:12, Jakub Jelinek wrote:
> On Tue, Nov 24, 2015 at 12:08:13PM +0100, Christophe Lyon wrote:
>> > Sure.
>> > I had a build in progress with your proposed patch, but it didn't
>> > complete before you committed :-)
>> >
>>
>> So... it still does not work for me. I re-tried
On Tue, Nov 24, 2015 at 12:08:13PM +0100, Christophe Lyon wrote:
> > Sure.
> > I had a build in progress with your proposed patch, but it didn't
> > complete before you committed :-)
> >
>
> So... it still does not work for me. I re-tried several times, made sure I had
> everything cleanup before
On 24 November 2015 at 10:21, Christophe Lyon
wrote:
> On 24 November 2015 at 09:58, Maxim Ostapenko
> wrote:
>> 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 tru
On 24 November 2015 at 09:58, Maxim Ostapenko
wrote:
> 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/Cha
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/libsa
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/libsanitizer/ChangeLog
> @@ -1,3 +1,7 @
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 following J
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 following Jakub's suggestion.
>
> Christophe
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:
#if de
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:
>
> #if defined(PTRACE_GETVFPREGS) && d
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 kernel version
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 kernel version?
>
Yes, I do use old kernel hea
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 kernel version?
Unlike LLVM, we do care to support older kernel headers.
So, if it is say a define, you
+ 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, Maxim Ostap
On 23 November 2015 at 09:07, Jakub Jelinek wrote:
> On Mon, Nov 23, 2015 at 10:46:33AM +0300, Maxim Ostapenko wrote:
>> Index: libsanitizer/configure.ac
>> ===
>> --- libsanitizer/configure.ac (revision 230597)
>> +++ libsanitizer/co
On Mon, Nov 23, 2015 at 10:48:30AM +0300, Maxim Ostapenko wrote:
> Index: gcc/testsuite/c-c++-common/asan/halt_on_error-1.c
> ===
> --- gcc/testsuite/c-c++-common/asan/halt_on_error-1.c (revision 0)
> +++ gcc/testsuite/c-c++-common/asa
On Mon, Nov 23, 2015 at 10:46:33AM +0300, Maxim Ostapenko wrote:
> Index: libsanitizer/configure.ac
> ===
> --- libsanitizer/configure.ac (revision 230597)
> +++ libsanitizer/configure.ac (working copy)
> @@ -136,6 +136,12 @@
> esac
>
This patch reflects to corresponding compiler changes. In particular, it
just enables -fsanitize-recover=address switch and migrates two small
testcases from upstream. I don't backport other stress tests because
they are heavy and have unstable output.
-Maxim
gcc/testsuite/ChangeLog:
2015-11-
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 10/20/2015 02:29 PM, Maxim Ostapenko wrote:
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.
Thanks, this should simplify work for other maintainers in future)
Some general remarks:
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 nuked
DASAN_FLEXIBLE_MAPPING_AND_OFFSET
On Tue, Oct 20, 2015 at 02:29:44PM +0300, Maxim Ostapenko wrote:
> 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.
I'd add a line that the diff in lib/asan/tests tests since the last
On Tue, Oct 20, 2015 at 02:19:51PM +0300, Maxim Ostapenko wrote:
> + a) Location's filename must not be NULL.
> + b) Location's filename must not be equal to "".
> + c) Location's filename must not be equal to "\1".
> + d) First two bytes of filename msut not contain '\xff' symbol. */
mus
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 nuked
> DASAN_FLEXIBLE_MAPPING_AND_OFFSET=0 (not used now) in corresponding
> Makefiles.
Ok.
Jakub
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
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
* saniti
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 (RegisterGlobal):
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/sanitizer_platform_limits_linux.c
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. asan_stack_malloc_[n] doesn't take a local stack as a second
parameter anymore, so don't pass it. Also, ubsan_instrument_float_cast
was adjuste
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
On Thu, Oct 15, 2015 at 01:34:06PM +0300, Maxim Ostapenko wrote:
> Ah, right, fixing this now. Does this looks better now?
Yes, it is ok now.
> 2015-10-12 Maxim Ostapenko
>
> config/
>
> * bootstrap-asan.mk: Replace ASAN_OPTIONS=detect_leaks with
> LSAN_OPTIONS=detect_leaks.
>
>
On Fri, Oct 16, 2015 at 02:29:08PM +0300, Maxim Ostapenko wrote:
> 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,
On 16 October 2015 at 14:59, Maxim Ostapenko
wrote:
> Yeah, thanks. Just wondering if I should step back until they are resolved
> upstream or we can have another merge in the future (stage3 is coming ...)?
Well, right now, the support is patchy, experimental, but it's
reasonably stable. From the
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
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 for all 3 possible VMA setti
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
heurist
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 what i
On 15 October 2015 at 10:21, wrote:
> So in summary just enable 48 bit va support in the upstream kernel right now
> and not needed to test on thunderx. So please enable 48 bit va in the kernel.
> It is supported on a kernel that supports juno, apm and amd processors.
Hi Andrew,
I'm sorry but
> On Oct 15, 2015, at 1:42 AM, Renato Golin wrote:
>
>> On 15 October 2015 at 08:29, Yury Gribov wrote:
>> Do you have any estimation for when full AArch64 support is ready in LLVM?
>> If it's still months away, I wonder if we may want to enable at least
>> current (partial) support for non-Th
On 15 October 2015 at 08:29, Yury Gribov wrote:
> Do you have any estimation for when full AArch64 support is ready in LLVM?
> If it's still months away, I wonder if we may want to enable at least
> current (partial) support for non-Thunder users.
Hi Yury,
Unfortunately, no. Basic support is the
On 14/10/15 20:17, Andrew Pinski wrote:
> On Wed, Oct 14, 2015 at 12:15 PM, Renato Golin
> wrote:
>> On 14 October 2015 at 20:00, Andrew Pinski wrote:
>>> Then until that happens I think we should disable asan and tsan for
>>> AARCH64 for GCC.
>>
>> I can't comment on that, but we'll continue
On 10/14/2015 10:15 PM, Renato Golin wrote:
On 14 October 2015 at 20:00, Andrew Pinski wrote:
Then until that happens I think we should disable asan and tsan for
AARCH64 for GCC.
I can't comment on that, but we'll continue running the tests on our
side on both 39 and 42 VMA configurations, to
On Wed, Oct 14, 2015 at 12:15 PM, Renato Golin wrote:
> On 14 October 2015 at 20:00, Andrew Pinski wrote:
>> Then until that happens I think we should disable asan and tsan for
>> AARCH64 for GCC.
>
> I can't comment on that, but we'll continue running the tests on our
> side on both 39 and 42 VM
On 14 October 2015 at 20:00, Andrew Pinski wrote:
> Then until that happens I think we should disable asan and tsan for
> AARCH64 for GCC.
I can't comment on that, but we'll continue running the tests on our
side on both 39 and 42 VMA configurations, to make sure we don't
regress until we actuall
On Wed, Oct 14, 2015 at 11:38 AM, 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 for all 3 possible VMA
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 for all 3 possible VMA settings. I suggest figuring
> this out first.
We are.
cheers
On Wed, Oct 14, 2015 at 11:03 AM, Adhemerval Zanella
wrote:
>
>
> On 14-10-2015 04: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.
On 14-10-2015 04: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
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-libasan.
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
> >>heuristic doesn't work for GCC, so perh
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 may be impleme
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 may be implemented as local patch for GCC?
No. Th
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 right location
On 10/14/2015 12:34 PM, Maxim Ostapenko wrote:
On 14/10/15 10:54, Jakub Jelinek wrote:
Do you plan to update the asan tests we have to reflect the changes in
upstream?
Hm, there aren't changes into instrumentation, so the only thing is new
interceptors. If it is desirable, I can migrate some t
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 wrong version)
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 wrong version).
> Here a fixed version of t
On 10/13/2015 02:16 PM, 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.
Also, asan_stack_malloc_[n] doesn't take a local stack as a second
parameter anymore, so don't pa
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 right location for now. I'm not sure about
> this,
On Tue, Oct 13, 2015 at 02:21:21PM +0300, Maxim Ostapenko wrote:
> 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.
I guess this is ok once all other changes are acked.
> 2015-10-
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-libasan. AFAIK, sanitizer developers use
> dif
1 - 100 of 434 matches
Mail list logo
