Greenhalgh james.greenha...@arm.com
Cc: Max Ostapenko, GCC Patches, Yury Gribov, Viacheslav Garbuzov, Trevor
Saunders, Maxim Ostapenko
Subject: Re: [PATCH] Add patch for debugging compiler ICEs
On 07/04/2014 07:21 PM, Jakub Jelinek wrote:
On Fri, Jul 04, 2014 at 04:13:31PM +0100, James Greenhalgh
://lkml.org/lkml/2014/7/9/990).
Bootstrapped and regtested on x64.
Ok to commit?
-Y
gcc/
2014-07-18 Yury Gribov y.gri...@samsung.com
* doc/invoke.texi (-fsanitize=kernel-address): Describe new option.
* flag-types.h (SANITIZE_KERNEL_ADDRESS): New enum.
* opts.c (common_handle_option): Handle
Also, oring in SANITIZER_ADDRESS means you add -lasan to link flags, I'd
guess that for -fsanitize=kernel-address you don't want to add any
libraries
at link time?
I suspect that we don't pass -fsanitize=kernel-address during linking
in kernel today. But I agree that it's better to
Author: Yury Gribov y.gri...@samsung.com
Date: Thu Jul 17 09:45:26 2014 +0400
Move inlining of Asan memory checks to sanopt pass.
Change asan-instrumentation-with-call-threshold to more closely match LLVM.
gcc/
2014-07-17 Yury Gribov y.gri...@samsung.com
Then in sanitize_spec_function supposedly for address check
SANITIZE_USER_ADDRESS bit, for kernel-address added there
SANITIZE_KERNEL_ADDRESS, add all the incompatibility diagnostics for the new
invalid combinations.
Ok.
Plus, toplev.c has e.g.:
...
Now, is the same really the case for
Author: Yury Gribov y.gri...@samsung.com
Date: Mon Jul 21 10:12:24 2014 +0400
2014-07-21 Yury Gribov y.gri...@samsung.com
check_GNU_style.sh: Support patches coming from stdin,
check that spaces are converted to tabs and make double-space
check more precice.
diff --git
On 05/09/2014 07:09 PM, Diego Novillo wrote:
I slightly prefer the semantics that gets me just the ChangeLog.
The workflow I'm envisioning is:
I've commited both patches in r212883 and r12884. Mklog now runs as a
filter and prints generated ChangeLog to stdout instead of modifying the
aa8d7cd3db1f1eba8ee77b902cff1b2ab2a3f83a
Author: Yury Gribov y.gri...@samsung.com
Date: Mon Jul 21 12:05:10 2014 +0400
2014-07-21 Yury Gribov y.gri...@samsung.com
* mklog: Allow running from arbitrary folder.
diff --git a/contrib/mklog b/contrib/mklog
index cdc6455..3d17dc5 100755
On 07/21/2014 11:00 PM, Alexey Preobrazhensky wrote:
This patch adds support for non-fixed shadow in asan stack instrumentation.
We probably also need to support non-fixed shadow in the middle-end
(the patch only implements it for RTL stack poisoner).
-Y
On 07/22/2014 02:24 AM, Sebastian Pop wrote:
What about getting clang-format to GNU format instead of improving
this ad-hoc script?
Well, GNU support in clang-format seems to be at it's early days
so improving diagnostic in check_GNU_style does not seem to be totally
useless.
In general
Attached patch delays generation of Asan memory checking
code until sanopt pass.
Here is an updated patch based on Jakub's review. Bootstrapped and
regtested on x64.
-Y
commit 7c371a6f462e166d3f2ad89afbe2e61b1a0b799b
Author: Yury Gribov y.gri...@samsung.com
Date: Thu Jul 17 09:45:26 2014
It is required for Kernel AddressSanitizer, as the shadow offset is
not known at the compile time,
To get shadow offset this patch uses function __asan_get_shadow_ptr.
Wouldn't be more effective just to read variable instead of function call?
Depends on how much logic you want to hide there.
This function just returns some global variable,
and I don't think we will need something more complex in future.
For kernel probably yes but what about userspace?
-Y
On 07/22/2014 05:57 PM, Richard Biener wrote:
I probably could
provide fnspec with (EAF_DIRECT | EAF_NOCLOBBER | EAF_NOESCAPE) or
even EAF_UNUSED for these functions but this does not seem
to be supported in current middle-end.
Simply add the fn spec attribute to the functions?
Problem is
decided to perform this check in finish_options (after passing
cmdline options).
Plus, toplev.c has e.g.:
Fixed as well.
-Y
commit bd51cdb807c2cf5ada0101ca7db89076b54ed18e
Author: Yury Gribov y.gri...@samsung.com
Date: Tue Jul 22 11:02:03 2014 +0400
2014-07-23 Yury Gribov y.gri
On 07/22/2014 12:27 PM, Yury Gribov wrote:
Attached patch delays generation of Asan memory checking
code until sanopt pass.
Here is an updated patch based on Jakub's review.
Bootstrapped and regtested on x64.
Yet another version with ASAN_CHECK changed to builtin function
(instead
On 07/24/2014 12:09 AM, Jakub Jelinek wrote:
Ah internal fns. Those cannot have attributes indeed (technical
limitation).
Martin was working on putting those flags elsewhere (cgraph, though internal
functions don't have cgraph nodes either ...). Maybe it was a bad idea to use
internal
Forwarded Message
Subject: [PATCH] Fix mklog to support running from arbitrary folder
Date: Mon, 21 Jul 2014 12:32:45 +0400
From: Yury Gribov y.gri...@samsung.com
To: GCC Patches gcc-patches@gcc.gnu.org
CC: Diego Novillo dnovi...@google.com, Trevor Saunders
tsaund
On 07/21/2014 12:55 PM, Trevor Saunders wrote:
I'm not really sure which is the better UI,
but I'd rather time be spent
on better automatic change log generation.
Yeah. Do you have some particular complaints btw?
I may or may not hope we'll
eventually have a mklog that can autogenerate most
On 07/24/2014 11:48 AM, Jakub Jelinek wrote:
So, either support for just EAF*, or perhaps support for DECL_ATTRIBUTES
for internal-fns, say by having some tree array where you'd store
what you
stick into DECL_ATTRIBUTES normally.
I'd prefer to avoid attributes. Would something like this be
On 07/28/2014 03:01 PM, Trevor Saunders wrote:
Yeah. Do you have some particular complaints btw?
I haven't actually used it in a while, but istr there's an issue where
if you change the prototype of a function mklog makes an entry for the
previous function.
I think this is because mklog
On 11/11/2014 08:42 PM, Jakub Jelinek wrote:
On Wed, Nov 05, 2014 at 11:50:20AM +0100, Jakub Jelinek wrote:
On Wed, Nov 05, 2014 at 11:29:19AM +0100, Marek Polacek wrote:
On Wed, Nov 05, 2014 at 12:54:37PM +0300, Yury Gribov wrote:
Are you going to work on ASan soon? I could rebase my
On 11/12/2014 04:52 AM, H.J. Lu wrote:
Hi,
This patch updates c-c++-common/asan/strlen-overflow-1.c to avoid tail
call on x32. Tested on Linux/x86-64/ia32/x32. OK to install?
Thanks.
H.J.
---
2014-11-11 H.J. Lu hongjiu...@intel.com
PR testsuite/63830
*
On 11/12/2014 01:34 PM, Jakub Jelinek wrote:
On Wed, Nov 12, 2014 at 12:18:31PM +0300, Yury Gribov wrote:
--- gcc/sanopt.c.jj 2014-11-11 09:13:36.698280115 +0100
+++ gcc/sanopt.c2014-11-11 18:07:17.913539517 +0100
@@ -49,6 +49,7 @@ along with GCC; see the file COPYING3.
#include
17 00:00:00 2001
From: Yury Gribov y.gri...@samsung.com
Date: Thu, 13 Nov 2014 21:29:51 +0300
Subject: [PATCH] 2014-11-14 Yury Gribov y.gri...@samsung.com
PR sanitizer/63802
gcc/
* stor-layout.c (min_align_of_type): Respect user alignment
more.
gcc/testsuite/
* c-c++-common/ubsan/pr63802.c
On 11/14/2014 10:02 AM, Jakub Jelinek wrote:
On Fri, Nov 14, 2014 at 09:46:14AM +0300, Yury Gribov wrote:
Hi all,
This patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63802 by only
limiting minimal type alignment with BIGGEST_ALIGNMENT for types with no
__attribute__((aligned
On 11/15/2014 09:34 PM, H.J. Lu wrote:
GCC uses xstrndup/xstrdup throughout the source tree and those memory
may not be freed explicitly before exut. LeakSanitizer isn't very
useful here. This patch suppresses LeakSanitizer in bootstrap. OK
for trunk?
Right, I think until now everyone just
On 11/17/2014 10:20 AM, Jakub Jelinek wrote:
On Fri, Nov 14, 2014 at 06:15:16PM +, Joseph Myers wrote:
On Fri, 14 Nov 2014, Jakub Jelinek wrote:
On Fri, Nov 14, 2014 at 09:46:14AM +0300, Yury Gribov wrote:
Hi all,
This patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63802
As for the generated code, I'm at the stage where I can implement the
following: if a single UBSan hander is used to report multiple error
kinds (__ubsan_handle_type_mismatch is used for
-fsanitize=null,alignment,object-size), and these kinds have different
recoverability, then we emit two
2657 checks in Asan-bootstrapped GCC
(out of ~500K).
I've Asan-bootstrapped, bootstrapped and regtested on x64.
Is this ok for stage3?
Best regards,
Yury
From 85f65c403f132245e9efcc8a420269f8d631fae6 Mon Sep 17 00:00:00 2001
From: Yury Gribov y.gri...@samsung.com
Date: Tue, 25 Nov 2014 11:49:11
on x64.
-Y
commit a9451a79bcdcab69856a38d228bec8986c0b0b2a
Author: Yury Gribov y.gri...@samsung.com
Date: Fri Aug 29 16:43:42 2014 +0400
2014-09-29 Yury Gribov y.gri...@samsung.com
gcc/
* asan.c (report_error_func): Optionally call recoverable
routines
) can't make this --param
because this can be a 64-bit value.
Bootstrapped and regtested on x64.
-Y
commit 05829f7922915b075c0f4275d3613947aa793a9c
Author: Yury Gribov y.gri...@samsung.com
Date: Fri Aug 29 11:58:03 2014 +0400
Allow to override Asan shadow offset.
2014-09-26 Yury
On 09/30/2014 04:24 AM, Konstantin Serebryany wrote:
On Mon, Sep 29, 2014 at 4:26 PM, Alexey Samsonov samso...@google.com wrote:
I don't think we ever going to support recovery for regular ASan
(Kostya, correct me if I'm wrong).
I hope so too.
Another point is that with
On 09/30/2014 09:40 AM, Jakub Jelinek wrote:
On Mon, Sep 29, 2014 at 05:24:02PM -0700, Konstantin Serebryany wrote:
I don't think we ever going to support recovery for regular ASan
(Kostya, correct me if I'm wrong).
I hope so too.
Another point is that with
On 09/30/2014 10:56 AM, Yury Gribov wrote:
On 09/30/2014 04:24 AM, Konstantin Serebryany wrote:
On Mon, Sep 29, 2014 at 4:26 PM, Alexey Samsonov samso...@google.com
wrote:
I don't think we ever going to support recovery for regular ASan
(Kostya, correct me if I'm wrong).
I hope so too
On 09/17/2014 09:08 PM, Yury Gribov wrote:
On 09/16/2014 08:38 PM, Yury Gribov wrote:
Hi all,
This is the third version of the patch. A list of changes since last
version:
* move config to contrib so that it's _not_ enabled by default (current
score is 2/1 in favor of no Vim config
Hi all,
This patch disables generation of asan_init calls for KASan as discussed
in https://lkml.org/lkml/2014/9/26/711
Bootstrapped and regtested no x64. Ok to commit?
-Y
commit 91c015e54687666f4abf6745f33c2eee8e569d17
Author: Yury Gribov y.gri...@samsung.com
Date: Fri Oct 3 11:53:38 2014
On 09/29/2014 09:21 PM, Yury Gribov wrote:
Hi all,
Kasan developers has asked for an option to override offset of Asan
shadow memory region. This should simplify experimenting with memory
layouts on 64-bit architectures.
New patch which checks that -fasan-shadow-offset is only enabled
On 10/06/2014 03:06 PM, Yury Gribov wrote:
On 09/29/2014 09:21 PM, Yury Gribov wrote:
Hi all,
Kasan developers has asked for an option to override offset of Asan
shadow memory region. This should simplify experimenting with memory
layouts on 64-bit architectures.
New patch which checks
On 10/02/2014 09:14 PM, Yury Gribov wrote:
On 09/17/2014 09:08 PM, Yury Gribov wrote:
On 09/16/2014 08:38 PM, Yury Gribov wrote:
Hi all,
This is the third version of the patch. A list of changes since last
version:
* move config to contrib so that it's _not_ enabled by default
On 10/06/2014 03:17 PM, Yury Gribov wrote:
On 10/06/2014 03:06 PM, Yury Gribov wrote:
On 09/29/2014 09:21 PM, Yury Gribov wrote:
Hi all,
Kasan developers has asked for an option to override offset of Asan
shadow memory region. This should simplify experimenting with memory
layouts on 64-bit
Hi all,
As discussed in https://gcc.gnu.org/ml/gcc/2014-09/msg00234.html , this
patchset backports mainline patches necessary for Kernel ASan in GCC 4.9
(gcc-4_9-branch). The patcheset consists of
* Asan headers installation (1 patch)
* __asan_loadN/__asan_storeN support (3 patches)
*
believe this
shouldn't influence portability in any way.
2014-10-15 Yury Gribov y.gri...@samsung.com
Backport from mainline
2014-05-14 Yury Gribov y.gri...@samsung.com
PR sanitizer/61100
* Makefile.am (nodist_saninclude_HEADERS): Install
public headers.
* Makefile.in: Regenerate
Further work on __asan_loadN/__asan_storeN. I removed the tests
(misalign-1.c, misalign-2.c) because (as mentioned in comments for
preceeding patch) __asan_loadN/__asan_storeN are disabled for userspace.
2014-10-15 Yury Gribov y.gri...@samsung.com
Backport from mainline
2014-05-30 Jakub
I disabled __asan_loadN/__asan_storeN because 4.9's Asan runtime doesn't
support them. In a later patch I re-enable these functions specifically
for KAsan.
2014-10-15 Yury Gribov y.gri...@samsung.com
Backport from mainline
2014-05-30 Jakub Jelinek ja...@redhat.com
* sanitizer.def
4.9's Asan runtime library provides no support for these so I removed
the tests. I've also changed default value of threshold to INT_MAX to
completely disable outline instrumentation in userspace Asan.
New asan-instrumentation-with-call-threshold parameter.
2014-10-15 Yury Gribov y.gri
Same as mainline.
2014-10-15 Yury Gribov y.gri...@samsung.com
Backport from mainline
2014-06-16 Yury Gribov y.gri...@samsung.com
* asan.c (build_check_stmt): Fix maybe-uninitialized warning.
diff --git a/gcc/asan.c b/gcc/asan.c
index 5c091d0..3729178 100644
--- a/gcc/asan.c
+++ b/gcc
Difference from mainline: replaced non-C-friendly bool with unsigned
char (see patch 0001 for explanation).
2014-10-15 Yury Gribov y.gri...@samsung.com
Backport from mainline
2014-06-18 Yury Gribov y.gri...@samsung.com
PR sanitizer/61547
* asan.c (instrument_strlen_call): Fixed
Same as mainline.
2014-10-15 Yury Gribov y.gri...@samsung.com
Backport from mainline
2014-06-18 Yury Gribov y.gri...@samsung.com
PR sanitizer/61530
* asan.c (build_check_stmt): Add condition.
* c-c++-common/asan/pr61530.c: New test.
diff --git a/gcc/asan.c b/gcc/asan.c
index 3729178
Difference from mainline: replaced non-C-friendly bool with unsigned
char (see patch 0001 for explanation).
Do not instrument first byte in strlen if already instrumented.
2014-10-15 Yury Gribov y.gri...@samsung.com
Backport from mainline
2014-06-24 Max Ostapenko m.ostape
The patch was slightly updated to take care of missing UBSan work
(SANITIZE_FLOAT_DIVIDE, SANITIZE_FLOAT_CAST, SANITIZE_BOUNDS).
2014-10-15 Yury Gribov y.gri...@samsung.com
Backport from mainline
2014-07-31 Yury Gribov y.gri...@samsung.com
* doc/cpp.texi (__SANITIZE_ADDRESS__): Updated
The patch was slightly updated to take care of missing UBSan work
(UBSAN_BOUNDS).
Move inlining of Asan memory checks to sanopt pass.
Change asan-instrumentation-with-call-threshold to more closely match LLVM.
2014-10-15 Yury Gribov y.gri...@samsung.com
Backport from mainline
2014-08-11
The patch was slightly updated to take care of missing UBSan work
(UBSAN_BOUNDS).
Added fnspec to internal functions.
2014-10-15 Yury Gribov y.gri...@samsung.com
Backport from mainline
2014-08-11 Yury Gribov y.gri...@samsung.com
* gimple.c (gimple_call_fnspec): Support internal
Same as mainline.
2014-10-15 Yury Gribov y.gri...@samsung.com
Backport from mainline
2014-08-12 Yury Gribov y.gri...@samsung.com
* internal-fn.c (init_internal_fns): Fix off-by-one.
diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c
index 0749dce..d64e20d 100644
--- a/gcc/internal-fn.c
Difference from mainline: replaced non-C-friendly bool with unsigned
char (see patch 0001 for explanation).
2014-10-15 Yury Gribov y.gri...@samsung.com
Backport from mainline
2014-08-18 Yury Gribov y.gri...@samsung.com
PR sanitizer/62089
* asan.c (instrument_derefs): Fix bitfield check
Same as mainline.
2014-10-15 Yury Gribov y.gri...@samsung.com
Backport from mainline
2014-08-28 Yury Gribov y.gri...@samsung.com
* c-c++-common/asan/pr62089.c: Fix test on 32-bit platforms.
diff --git a/gcc/testsuite/c-c++-common/asan/pr62089.c b/gcc/testsuite/c-c++-common/asan/pr62089
Same as mainline.
2014-10-15 Yury Gribov y.gri...@samsung.com
Backport from mainline
2014-09-01 Yury Gribov y.gri...@samsung.com
PR sanitizer/61897
PR sanitizer/62140
* asan.c (asan_mem_ref_get_end): Handle non-ptroff_t lengths.
(build_check_stmt): Likewise.
(instrument_strlen_call
Same as mainline.
2014-10-15 Yury Gribov y.gri...@samsung.com
Backport from mainline
2014-10-03 Yury Gribov y.gri...@samsung.com
* asan.c (asan_finish_file): Disable __asan_init calls for KASan;
don't emit empty ctors.
diff --git a/gcc/asan.c b/gcc/asan.c
index 5c6d1c5..b8fbed3 100644
Not a backport, specifically enables said instructions in KASan.
Instrument unaligned objects in KASan.
2014-10-15 Yury Gribov y.gri...@samsung.com
* asan.c (instrument_derefs): Enable unaligned path for KASan.
diff --git a/gcc/asan.c b/gcc/asan.c
index b8fbed3..db4e3a0 100644
--- a/gcc
On 10/16/2014 12:49 PM, Jakub Jelinek wrote:
On Thu, Oct 16, 2014 at 12:39:17PM +0400, Yury Gribov wrote:
Difference from mainline: replaced non-C-friendly bool with unsigned char
(see patch 0001 for explanation).
Where? I don't see unsigned char being used anywhere in the patch.
bool
On 10/17/2014 11:27 AM, Eric Botcazou wrote:
The patch was slightly updated to take care of missing UBSan work
(SANITIZE_FLOAT_DIVIDE, SANITIZE_FLOAT_CAST, SANITIZE_BOUNDS).
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -868,6 +868,20 @@ finish_options (struct gcc_options *opts, struct
gcc_options
Hi all,
On 09/29/2014 09:21 PM, Yury Gribov wrote:
Kasan developers has asked for an option to override offset of Asan
shadow memory region. This should simplify experimenting with memory
layouts on 64-bit architectures.
New patch which checks that -fasan-shadow-offset is only enabled
On 10/17/2014 11:43 AM, Eric Botcazou wrote:
Well, that's a backport of ancient patch from trunk so all credits go
there. And flag_sanitize is indeed handled differently from other
compiler flags.
Really curious to know why...
I bet this was a typo but let's wait for Jakub's comments.
-Y
On 10/17/2014 04:24 PM, Jakub Jelinek wrote:
+/* Returns TRUE if given FCODE corresponds to string or memory builtin
function.
+ */
+
+static inline bool
+is_memory_builtin (enum built_in_function fcode)
+{
+ return fcode = BUILT_IN_STRSTR fcode = BUILT_IN_BCMP;
This is too fragile and
On 10/17/2014 04:12 PM, Jakub Jelinek wrote:
I had a brief look at what ended up on the branch in the end, and
from what I understand, the 4.9 libasan.so has
__asan_report_store_n and __asan_report_load_n entry points, but does
not have any __asan_loadN/__asan_reportN entrypoints (neither
On 10/17/2014 05:49 PM, Jakub Jelinek wrote:
Plus if you add misalign tests...
Sure, can do this on Monday.
- bool use_calls = ASAN_INSTRUMENTATION_WITH_CALL_THRESHOLD INT_MAX
- asan_num_accesses = ASAN_INSTRUMENTATION_WITH_CALL_THRESHOLD;
+ bool use_calls
+=
On 10/17/2014 06:18 PM, Jakub Jelinek wrote:
On Fri, Oct 17, 2014 at 06:15:11PM +0400, Yury Gribov wrote:
On 10/17/2014 05:49 PM, Jakub Jelinek wrote:
Plus if you add misalign tests...
Sure, can do this on Monday.
Ok, thanks.
- bool use_calls = ASAN_INSTRUMENTATION_WITH_CALL_THRESHOLD
On Fri, Oct 17, 2014 at 06:15:11PM +0400, Yury Gribov wrote:
On 10/17/2014 05:49 PM, Jakub Jelinek wrote:
So, what about this? Just checked that with
make -k check-g{cc,++}
RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} asan.exp tsan.exp ubsan.exp'
so far. Plus if you add misalign tests
On 10/17/2014 08:13 PM, Jakub Jelinek wrote:
On Mon, Oct 13, 2014 at 02:47:07PM +0400, Yury Gribov wrote:
On 09/30/2014 09:39 PM, Jakub Jelinek wrote:
LGTM, will hack it up soon in GCC then.
Do you plan to work on this in near future?
Here is only very lightly tested patch, didn't get
to hide warnings from -Wlong-long.
Unfortunately it does not fix spurious warnings for long long constants
in older versions of GCC
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7263). I guess that's fine.
-Y
commit d78d8daeec19531014c703894dc67db1430f6cbb
Author: Yury Gribov y.gri...@samsung.com
But if somebody is willing to maintain it for
cross-testing
Yup, we'll do this.
Now what bothers me is zero feedback from Dejagnu folks...
-Y
This patch adds initial set of tests and dg infrastructure for
LeakSanitizer runtime.
Are you sure we need testsuite for something that doesn't have a GCC code
generation counterpart at all?
That's a valid point. We want this in GCC because
(1) support for cross-compilation and cross-testing
It is unfortunate there is no way to forcefully disable the colorization,
e.g. through some env var.
I think they have ASAN_OPTIONS=color=0 (or something like that) but ssh
targets (still) don't support passing environment variables.
-Y
--
From: Yury Gribov y.gri...@samsung.com
Sent: Tuesday, March 25, 2014 11:57AM
To: Jakub Jelinek ja...@redhat.com, Eric Botcazou
ebotca...@adacore.com, gcc-patches@gcc.gnu.org, Hans-Peter Nilsson
h...@bitrange.com, rdsandif...@googlemail.com
Hi Trevor,
I think this looks rather useful.
+if (-d .git) {
What about moving default name/addr (with finger, etc.) to else branch?
+ chomp($gitname);
+ chomp($gitaddr);
Missing whites before (.
-Y
+# XXX We should probably accept /dev/stdin or maybe magic autodetection of
+# being supposed to get the patch from stdin.
+#
Can we just set $diff to '-' if @ARGV is empty?
+# In any case if we got the diff on stdin then write the ChangeLog to stdout.
Hm, this is breaks semantics: you only
I agree stdin gets different semantics than other files but I think
that's sort of ok because it means you generated the patch somehow so
presumably you can do that again if you need the patch.
True but this would be a surpising behavior for ordinary Linux user. We
can wait for Diego's
On 04/29/2014 02:06 PM, Trevor Saunders wrote:
+if (-d .git) {
What about moving default name/addr (with finger, etc.) to else branch?
Well, consider the case git doesn't know
I wonder whether it's ok to force user to configure git before running
mklog...
-Y
v.garbu...@samsung.com, Yury Gribov y.gri...@samsung.com
Hi,
This fixes infinite backtrace in __cxa_end_cleanup().
Regtest was finished with no regressions on arm-linux-gnueabi(sf).
The patch posted at:
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00496.html
Thanks in advance.
Best regards
On 05/12/2014 03:20 PM, Konstantin Serebryany wrote:
This is the first libsanitizer merge in 4.10
Thanks, Kostya.
I see that ASAN_DYNAMIC is not fully supported in libsanitizer
Makefiles, I'll work on this once your patch goes in. I also have
pending patch for
On 05/12/2014 08:16 PM, Konstantin Serebryany wrote:
Thanks! May I ask you to contribute the patch upstream?
https://code.google.com/p/address-sanitizer/wiki/HowToContribute
Note that we wouldn't be able to repro in upstream because
* ARM isn't supported
* LLVM won't build with gcc 4.6 anyway
* ARM isn't supported
I meant ARM-Linux.
-Y
On 05/12/2014 08:18 PM, Konstantin Serebryany wrote:
Didn'thttp://llvm.org/viewvc/llvm-project?view=revisionrevision=208530 help?
Ah true, I missed the fact that you define PIC in libsanitizer/configure.
-Y
Your current policy seems to massively impede contributions.
How? (BTW, I am not the one who sets these policies and discussing
them with me makes little sense)
I think people are mainly worried with checking out Clang, making it to
build (install Cmake, C++11-friendly compiler, etc.), then
Hi,
Asan and Tsan allow sanitized applications to tweak runtime behavior via
API defined in headers in libsanitizer/include/sanitizer. This patch
adds installation code for these headers and a small test.
Bootstrapped and regtested on x64.
-Y
libsanitizer/ChangeLog:
2014-05-13 Yury Gribov
Bootstrapped and regtested on x64.
Forgot to mention: the newly added test currently fails for C because of
C++-isms in asan_interface.h but this should be fixed with next merge
from LLVM.
-Y
On 05/14/2014 08:54 AM, Konstantin Serebryany wrote:
Shouldn't we just install the entire include/sanitizer directory?
Well, I'd say we should only install headers for components that are
supported by target platform.
-Y
On 05/14/2014 10:29 AM, Konstantin Serebryany wrote:
Well, I'd say we should only install headers for components that are
supported by target platform.
maybe yes. It just complicates the patch somewhat.
True... But this seems to be the preferred way in GCC (other runtimes
also list headers
On 05/14/2014 10:46 AM, Jakub Jelinek wrote:
Ok.
Thanks, submitted in r210413.
-Y
On 05/14/2014 08:51 AM, Konstantin Serebryany wrote:
One theme I have been noticing in the libsanitizer code is that it has
all of the knowledge of glibc when it comes to syscalls but makes some
bad assumptions dealing with some structures. For an example on MIPS
n64: stat and stat64 are
On 05/15/2014 12:05 PM, Konstantin Serebryany wrote:
No. We have to support too many build systems and hence do not want
any configure step.
All configuration has to be done in the sources.
Yeah, I see your point. But filling code with magic constants isn't very
nice either.
We could make a
For now, please revert your original patch
Alex asked me to revert patch for him. Done in r210650.
-Y
The new test fails on x86_64 Ubuntu 12.04 native build:
Yes, this should be fixed once kcc's patches get into trunk
(https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00756.html). Current
asan_interface.h is indeed C++-only.
-Y
On 05/22/2014 11:54 PM, Jakub Jelinek wrote:
Kostya, guess you should ignore the vDSO.
Right, we didn't encounter this problem when testing on our kernels.
I'll cook a patch for this.
much better would be just dlsym a couple of
interesting symbols to verify that libasan.so.1 is ahead
of
On 05/23/2014 10:34 AM, Jakub Jelinek wrote:
Otherwise libasan apps will simply stop
working altogether if LD_PRELOAD is set, to whatever library,
even if it doesn't define any symbols you care about.
Right but I'm not sure whether failing fast here is necessarily bad.
I think it is very
On ARM the asan tests have always been a random generator of PASS /
FAIL on qemu despite efforts to nobble qemu for /proc/self/maps
outputs.
This should improve once upstream Asan sets up an ARM build bot. This
has been discussed recently but noone has yet volunteered to do the
server
Paolo,
I've checked all available systems and wasn't able to repro this.
Every time vDSO was already filtered with
if (!info-dlpi_name || info-dlpi_name[0] == 0)
return 0;
in FindFirstDSOCallback.
Could you provide additional details of your setup? Or perhaps print
dlpi_name of
I've checked all available systems and wasn't able to repro this.
Given your exchanges with Jakub I thought that at this point it was
clear that the issue is real.
There are three issues here:
1) whether warning should cause termination
2) whether warning should be displayed by default
3) why
still should have come up on your machine in the first place.
should not have
Could you add something like
It's always linux-vdso.so.1, but wasn't that already known, given the
ldd requested by Jakub?!?
Well, for me dlpi_name for vdso was empty string hence I kept asking. I
also thought that ldd and dl_iterate_phdr might have used slightly
different code paths when
1 - 100 of 387 matches
Mail list logo
