Cool, we don't have this in LLVM-ASan, but we have plans to instrument
inline asm soon (not just constraints).
asm-struct-1.c test looks like a false positive though - the code does
not access any invalid memory, it only does a harmless pointer cast.
On Wed, May 28, 2014 at 10:36 PM, Konstantin
Hi Christophe,
is there anything special about your setup? We've seen it build on
arm/linux and arm/android correctly.
On Fri, May 23, 2014 at 6:06 PM, Christophe Lyon
christophe.l...@linaro.org wrote:
Hi,
Since merge from upstream r209283 (210743 in GCC), my build fails on
ARM, because
[plain text version]
Tool-specific actions in the interceptors are disabled when we enter
the symbolizer.
What happens if user app links libbacktrace? An instrumented
libbacktrace? Memory that is allocated internally in sanitizer runtime
is not unpoisoned; for example, asan may consider it
On Wed, Nov 6, 2013 at 3:53 AM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Nov 05, 2013 at 01:49:43PM -0800, Evgeniy Stepanov wrote:
This way we can't test kernel interfaces that are not used in glibc,
like linux aio.
So you just test what you can test. Why do you need to intercept kernel
On Tue, Nov 5, 2013 at 10:07 AM, Peter Bergner berg...@vnet.ibm.com wrote:
On Tue, 2013-11-05 at 09:57 -0600, Peter Bergner wrote:
On Tue, 2013-11-05 at 08:19 +0100, Jakub Jelinek wrote:
Note, not even glibc itself includes asm/stat.h, so the chances of that
header actually working for you
On Tue, Nov 5, 2013 at 10:45 AM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Nov 05, 2013 at 10:17:09AM -0800, Evgeniy Stepanov wrote:
On Tue, Nov 5, 2013 at 10:07 AM, Peter Bergner berg...@vnet.ibm.com wrote:
On Tue, 2013-11-05 at 09:57 -0600, Peter Bergner wrote:
On Tue, 2013-11-05 at 08
Hi,
r194664 in google/gcc-4_7 lost one line in
libstdc++-v3/libsupc++/Makefile.am and did not regenerate Makefile.in
(it seems to have been edited manually).
Now re-running automake in libstdc++ results in a non-trivial diff.
The attached patch updates Makefile.am. With this patch the
OK to merge to google/4_7 and google/4_8?
On Wed, May 15, 2013 at 12:28 PM, Evgeniy Stepanov euge...@google.com wrote:
Thanks!
On Wed, May 15, 2013 at 3:05 AM, Jonathan Wakely jwakely@gmail.com
wrote:
On 14 May 2013 10:56, Jonathan Wakely wrote:
On 14 May 2013 10:45, Evgeniy Stepanov
review please?
On Mon, May 13, 2013 at 6:12 PM, Evgeniy Stepanov euge...@google.com wrote:
re-sending the patch
On Mon, May 13, 2013 at 5:54 PM, Evgeniy Stepanov euge...@google.com wrote:
friendly ping
On Mon, Apr 22, 2013 at 5:23 PM, Evgeniy Stepanov euge...@google.com wrote:
Hi
On Mon, May 20, 2013 at 5:17 PM, Jonathan Wakely jwakely@gmail.com wrote:
On 20 May 2013 14:15, Evgeniy Stepanov wrote:
review please?
I suggest you CC whoever approves changes for the google branches, maybe
Diego?
rdrand.patch
Description: Binary data
in trunk) does
m4_include([../config/gthr.m4])
GCC_AC_THREAD_HEADER([$target_thread_file])
Again, this new code seems to work perfectly in 4_7 branch. My guess
is committer just was not interested in 4_7 by the time of re-commit.
On Tue, May 14, 2013 at 5:32 PM, Evgeniy Stepanov euge
This must have fallen through the cracks.
I realized we also need it in the 4_7 branch. Could you backport the
change there, too, if it is not too much trouble?
On Mon, Apr 22, 2013 at 10:53 PM, Jonathan Wakely jwakely@gmail.com wrote:
On 22 April 2013 12:13, Evgeniy Stepanov wrote:
Thanks
Hi,
this patch merges r192458 into gcc-4_7 to fix separate configure/build
of libstdc++.
A bit of history: a similar patch was committed to trunk 4.7 back in
Oct'12, then reverted from both, than this patch was committed to
trunk only. I wonder if it was simply lost for some reason?
Is it OK
/testsuite/Makefile.in: Regenerate.
On Tue, May 14, 2013 at 5:24 PM, Jonathan Wakely jwakely@gmail.com wrote:
On 14 May 2013 14:14, Evgeniy Stepanov wrote:
Hi,
this patch merges r192458 into gcc-4_7 to fix separate configure/build
of libstdc++.
A bit of history: a similar patch was committed
friendly ping
On Mon, Apr 22, 2013 at 5:23 PM, Evgeniy Stepanov euge...@google.com wrote:
Hi,
this patch disables rdrand in c++11/random.cc when building with Clang
compiler. Current Clang misses a number of definitions needed to build
that.
Is it OK for google/gcc-4_8 and google/main
re-sending the patch
On Mon, May 13, 2013 at 5:54 PM, Evgeniy Stepanov euge...@google.com wrote:
friendly ping
On Mon, Apr 22, 2013 at 5:23 PM, Evgeniy Stepanov euge...@google.com wrote:
Hi,
this patch disables rdrand in c++11/random.cc when building with Clang
compiler. Current Clang
On Tue, May 7, 2013 at 9:33 AM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
+euge...@google.com (our ARM expert)
Christophe,
The change in sanitizer_common/sanitizer_stacktrace.cc changes the
logic which is known to work well for us on Android/ARM.
I'd like Evgeniy to
Thanks a lot.
Forgot to mention it earlier, can this be backported in the 4_8 branch as well?
On Sun, Apr 21, 2013 at 12:40 PM, Jonathan Wakely jwakely@gmail.com wrote:
On 19 April 2013 16:19, Evgeniy Stepanov wrote:
Good point, thanks!
Revised patch attached.
I've committed that version
Hi,
this patch disables rdrand in c++11/random.cc when building with Clang
compiler. Current Clang misses a number of definitions needed to build
that.
Is it OK for google/gcc-4_8 and google/main (or google/integration?) ?
rdrand.patch
Description: Binary data
Hi,
according to n3242 8.5.6,
If a program calls for the default initialization of an object of a
const-qualified type T, T shall be a class type with a user-provided
default constructor.
This patches fixes 3 places in libstdc++ code where this requirement
is violated.
Please review.
I don't
Good point, thanks!
Revised patch attached.
On Fri, Apr 19, 2013 at 7:00 PM, Jonathan Wakely jwakely@gmail.com wrote:
On 19 April 2013 15:42, Evgeniy Stepanov wrote:
Hi,
according to n3242 8.5.6,
If a program calls for the default initialization of an object of a
const-qualified type T
On Thu, Mar 28, 2013 at 11:36 AM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
+euge...@google.com
Hi Christophe,
On Thu, Mar 28, 2013 at 2:09 AM, Christophe Lyon
christophe.l...@linaro.org wrote:
Hi,
This small patch enables libsanitizer on ARM.
It has been tested
:01PM +0400, Evgeniy Stepanov wrote:
What if glibc adds a scanf hook (like it has already printf hooks),
apps
could then register their own stuff and the above would then break. It
really should be very conservative, and should be checked e.g. with all
glibc's *scanf tests (e.g
Yes, this looks good. I've added some tests and committed to
compiler-rt. Thanks!
On Tue, Feb 12, 2013 at 5:46 PM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Feb 12, 2013 at 05:28:53PM +0400, Evgeniy Stepanov wrote:
Hey,
seems like that last of the scanf changes are in.
We're intercepting
On Mon, Feb 11, 2013 at 3:38 PM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Jan 23, 2013 at 04:24:01PM +0400, Evgeniy Stepanov wrote:
What if glibc adds a scanf hook (like it has already printf hooks), apps
could then register their own stuff and the above would then break. It
really
SANITIZER_INTERCEPT_SCANF 0
(see comments below). Ok with those changes.
Done, added Evgeniy Stepanov.
No changes for the ppc64 address space issue?
Not yet.
Do you think that can be done
say before end of month for yet another merge?
I hope so.
Also, I'd appreciate
On Wed, Jan 23, 2013 at 4:39 PM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Jan 23, 2013 at 04:24:01PM +0400, Evgeniy Stepanov wrote:
So, e.g. whenever match_spec
returns 0, it should break out of the loop, rather than continue.
And for %hh it doesn't check following letters
, 2012 at 12:10 AM, Evgeniy Stepanov
eugeni.stepa...@gmail.com wrote:
I'm looking into the empty stack issue, at this point it looks like a weird
linker bug. But its completely orthogonal to this discussion.
I recall that the stack trace of the offending memory access has in fact
three extra
The ARM/Android failure is due to libstdc++ in android-ndk-r8b not
containing debug info. As a result, stack unwinding breaks in
operator new, after exactly 2 frames. I guess we can simply tweak
the assert to be OK with empty stack traces when user code stack can
not be unwinded.
Matching FP or
Ok, fine.
On Tue, Nov 20, 2012 at 6:47 PM, Dmitry Vyukov dvyu...@google.com wrote:
On Tue, Nov 20, 2012 at 6:21 PM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
On Tue, Nov 20, 2012 at 6:18 PM, Evgeniy Stepanov
eugeni.stepa...@gmail.com wrote:
On Tue, Nov 20, 2012 at 5:52
30 matches
Mail list logo
