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
wrote:
> Hi,
> Since merge from upstream r209283 (210743 in GCC), my build fails on
> ARM, because rpc/xdr.h is not found.
> Is
[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 unaddr
On Wed, Nov 6, 2013 at 3:53 AM, Jakub Jelinek 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
On Tue, Nov 5, 2013 at 10:45 AM, Jakub Jelinek 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 wrote:
>> > On Tue, 2013-11-05 at 09:57 -0600, Peter Bergner wrote:
>> >> On Tue, 2013-11-05
On Tue, Nov 5, 2013 at 10:07 AM, Peter Bergner 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 , so the chances of that
>> > header actually working for you are low. glibc instead
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 difference
OK to merge to google/4_7 and google/4_8?
On Wed, May 15, 2013 at 12:28 PM, Evgeniy Stepanov wrote:
> Thanks!
>
> On Wed, May 15, 2013 at 3:05 AM, Jonathan Wakely
> wrote:
>> On 14 May 2013 10:56, Jonathan Wakely wrote:
>>> On 14 May 2013 10:45, Evgeniy Stepanov
ently 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 wrote:
&
On Mon, May 20, 2013 at 5:17 PM, Jonathan Wakely 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
review please?
On Mon, May 13, 2013 at 6:12 PM, Evgeniy Stepanov wrote:
> re-sending the patch
>
> On Mon, May 13, 2013 at 5:54 PM, Evgeniy Stepanov wrote:
>> friendly ping
>>
>> On Mon, Apr 22, 2013 at 5:23 PM, Evgeniy Stepanov wrote:
>>> Hi,
>>
Thanks!
On Wed, May 15, 2013 at 3:05 AM, Jonathan Wakely wrote:
> On 14 May 2013 10:56, Jonathan Wakely wrote:
>> On 14 May 2013 10:45, Evgeniy Stepanov wrote:
>>> This must have fallen through the cracks.
>>
>> It's still in my Git branch at home. I'
++-v3/testsuite/Makefile.in: Regenerate.
On Tue, May 14, 2013 at 5:24 PM, Jonathan Wakely 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
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 f
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 wrote:
> On 22 April 2013 12:13, Evgeniy Stepanov wrote:
>> Thanks a lot.
re-sending the patch
On Mon, May 13, 2013 at 5:54 PM, Evgeniy Stepanov wrote:
> friendly ping
>
> On Mon, Apr 22, 2013 at 5:23 PM, Evgeniy Stepanov wrote:
>> Hi,
>>
>> this patch disables rdrand in c++11/random.cc when building with Clang
>> compiler.
friendly ping
On Mon, Apr 22, 2013 at 5:23 PM, Evgeniy Stepanov 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 g
On Tue, May 7, 2013 at 9:33 AM, Konstantin Serebryany
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 comment on it.
>
> --kcc
>
> O
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
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 wrote:
> On 19 April 2013 16:19, Evgeniy Stepanov wrote:
>> Good point, thanks!
>> Revised patch attached.
>
> I've committed
Good point, thanks!
Revised patch attached.
On Fri, Apr 19, 2013 at 7:00 PM, Jonathan Wakely 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
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 hav
On Thu, Mar 28, 2013 at 11:36 AM, Konstantin Serebryany
wrote:
> +euge...@google.com
>
> Hi Christophe,
>
> On Thu, Mar 28, 2013 at 2:09 AM, Christophe Lyon
> wrote:
>> Hi,
>> This small patch enables libsanitizer on ARM.
>> It has been tested successfully on cortex-a9 hardware (via the GCC
>> t
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 wrote:
> On Tue, Feb 12, 2013 at 05:28:53PM +0400, Evgeniy Stepanov wrote:
>> Hey,
>>
>> seems like that last of the scanf changes are
built with different libc versions.
Thanks for the help with scanf testing, we've got much more confidence
in our implementation now.
On Mon, Feb 11, 2013 at 5:55 PM, Jack Howarth wrote:
> On Mon, Feb 11, 2013 at 12:38:00PM +0100, Jakub Jelinek wrote:
>> On Wed, Jan 23, 2013 at 0
On Mon, Feb 11, 2013 at 3:38 PM, Jakub Jelinek 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 th
On Wed, Jan 23, 2013 at 4:39 PM, Jakub Jelinek 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
ommit?
> >
> > Please mention
> > PR sanitizer/55989
> > in the ChangeLog entry, as this should fix that issue.
>
> done.
>
> >
> > If you want to commit now, I'd prefer if you could for now change
> > # define SANITIZER_INTERCEPT_SCANF SI_NOT_WINDOWS
> >
ov 22, 2012 at 12:10 AM, Evgeniy Stepanov
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
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 wrote:
> On Tue, Nov 20, 2012 at 6:21 PM, Konstantin Serebryany
> wrote:
>> On Tue, Nov 20, 2012 at 6:18 PM, Evgeniy Stepanov
>> wrote:
>>> On Tue, Nov 20, 2012 at 5:52 PM, Konstantin Serebryany
>>&
31 matches
Mail list logo
