the malloc like wrappers. The distance from there to
> the leaf should not he too far, right?
Hm? You mean the code has xalloc() which calls malloc()?
No problem, just one extra frame to unwind and store.
--kcc
>
> David
>
>
> On Thu, Nov 15, 2012 at 9:36 AM, Konstantin Sereb
I see no problems with committing mach_override to gcc.
The code should be verbatim copy from
llvm/projects/compiler-rt/lib/interception/mach_override
Note that this code comes with an MIT license and was not developed by
Google (we did add quite a few patches).
Sorry for delay with replies, I am
On Thu, Nov 15, 2012 at 5:01 PM, Andrew Pinski wrote:
> On Wed, Nov 14, 2012 at 2:59 PM, Jakub Jelinek wrote:
>> On Wed, Nov 14, 2012 at 11:12:05AM -0800, Mike Stump wrote:
>>> On Nov 14, 2012, at 8:22 AM, Jakub Jelinek wrote:
>>> > On Wed, Nov 14, 2012 at 12:11:13PM +0100, Jakub Jelinek wrote:
On Fri, Nov 16, 2012 at 3:08 PM, Peter Bergner wrote:
> Attached below is an initial port of ASAN to powerpc*-linux.
> With the patch below along with Jakub's ASAN testsuite patch:
>
> http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01365.html
>
> ASAN not only builds, but seems to be working.
Out
On Sat, Nov 17, 2012 at 4:14 PM, David Miller wrote:
> From: "H.J. Lu"
> Date: Sat, 17 Nov 2012 16:06:23 -0800
>
>> On Sat, Nov 17, 2012 at 4:04 PM, David Miller wrote:
>>> From: Eric Botcazou
>>> Date: Sun, 18 Nov 2012 00:18:15 +0100
>>>
error: '__NR_mmap2' was not declared in this scope
On Sat, Nov 17, 2012 at 7:10 PM, David Miller wrote:
> From: Konstantin Serebryany
> Date: Sat, 17 Nov 2012 19:01:56 -0800
>
>> I am open to suggestions on how to avoid forking the two versions.
>> If we fork, the original asan team will not be able to cope with two
>
On Sat, Nov 17, 2012 at 7:26 PM, Diego Novillo wrote:
> On Sat, Nov 17, 2012 at 10:10 PM, David Miller wrote:
>> From: Konstantin Serebryany
>> Date: Sat, 17 Nov 2012 19:01:56 -0800
>>
>>> I am open to suggestions on how to avoid forking the two versions.
>>
On Sun, Nov 18, 2012 at 7:34 AM, Andrew Pinski wrote:
> On Sat, Nov 17, 2012 at 7:17 PM, Konstantin Serebryany
> wrote:
>> On Sat, Nov 17, 2012 at 7:10 PM, David Miller wrote:
>>> From: Konstantin Serebryany
>>> Date: Sat, 17 Nov 2012 19:01:56 -0800
>>>
As for the libsanitizer update process, I suggest to move the
discussion to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55376
On Sun, Nov 18, 2012 at 7:42 AM, Konstantin Serebryany
wrote:
> On Sun, Nov 18, 2012 at 7:34 AM, Andrew Pinski wrote:
>> On Sat, Nov 17, 2012 at 7:17 PM, K
Just a comment about tsan.
Today, tsan works *only* on x86_64 linux (no 32-bits, no non-linux).
Other 64-bit platforms may be doable, but not as easy as for asan.
Non-linux is harder than non-x86_64 (need to support tons of libc interceptors).
32-bit platforms are very hard to port to, I would not
version into gcc.
In the meantime, feel free to apply the exact same patch manually.
--kcc
On Sun, Nov 18, 2012 at 8:07 AM, Konstantin Serebryany
wrote:
> As for the libsanitizer update process, I suggest to move the
> discussion to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55376
>
> Does -faddress-sanitizer add a CPP symbol that lets you work around it?
> If not, it's a bug. If so, please make libcpp revert to the dump
> algorithm if said symbol is defined.
Do you mean, does asan compilation cause some special preprocessor
symbol to be defined?
No, asan compilation does
On Sat, Nov 17, 2012 at 3:08 AM, Peter Bergner wrote:
> Attached below is an initial port of ASAN to powerpc*-linux.
> With the patch below along with Jakub's ASAN testsuite patch:
>
> http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01365.html
>
> ASAN not only builds, but seems to be working. The
On Mon, Nov 19, 2012 at 6:49 PM, Peter Bergner wrote:
> On Mon, 2012-11-19 at 15:29 +0100, Jakub Jelinek wrote:
>> On Fri, Nov 16, 2012 at 05:08:06PM -0600, Peter Bergner wrote:
>> > One question that I have is that the toplev.c test for port support
>> > tests for !FRAME_GROWS_DOWNWARD. The rs60
FYI
Clang also supports the no- form (-fno-sanitize=address).
We probably want it here too, but preferably as a separate patch.
(or is it automatically implemented via some internal magic?)
--kcc
On Mon, Nov 19, 2012 at 10:14 PM, Wei Mi wrote:
> Hi,
>
> This patch is to change -faddress-sanitize
On Mon, Nov 19, 2012 at 10:44 PM, Tobias Burnus wrote:
> Dear all,
>
> attached is a first draft for -faddress-sanitizer in the release notes.
>
> I am aware that some changes are imminent,* but I want make a start.
> Comments?
stack overflow is something different, I guess we want to say "stack
On Mon, Nov 19, 2012 at 10:31 PM, Xinliang David Li wrote:
> Questions: are -fsanitize=thread -fsanitize=address mutually exclusive
> here? If yes, that will be wrong.
>
> How about -fsanitize=all option?
asan and tsan can not coexist in the same process.
Until recently, using both flags with cla
On Mon, Nov 19, 2012 at 11:21 PM, Wei Mi wrote:
> I cannot remove RejectNegative and use -fno-sanitize=address, or else
> I will break an assertion (opts-common.c:614). The assertion requires
> -fxxx=var options set RejectNegative if var is of enumerater type. I
> see that all the other -fxxx=xx
On Tue, Nov 20, 2012 at 9:16 AM, David Miller wrote:
>
> I don't think it's reasonable that the sparc bootstrap is still broken
> in the tree, even though a fix has existed for nearly a week.
>
> It is not acceptable to say "everyone has to apply a special patch
> until some external dependency th
that's what we are moving to in clang (e.g. "ubsan" can co-exist
with tsan/tsan/msan).
>
> David
>
> On Mon, Nov 19, 2012 at 9:07 PM, Konstantin Serebryany
> wrote:
>> On Mon, Nov 19, 2012 at 10:31 PM, Xinliang David Li
>> wrote:
>>> Questio
On Tue, Nov 20, 2012 at 9:26 AM, David Miller wrote:
> From: Konstantin Serebryany
> Date: Tue, 20 Nov 2012 09:20:29 +0400
>
>> Please do (the same that was applied upstream).
>
> Which one was that?
http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/sanitizer_common/
On Tue, Nov 20, 2012 at 12:04 AM, Peter Bergner wrote:
> On Fri, 2012-11-16 at 15:47 -0800, Konstantin Serebryany wrote:
>> On Fri, Nov 16, 2012 at 3:08 PM, Peter Bergner wrote:
>> > The lone ASAN
>> > test case does fail, but it seems to be related to us using
>
On Tue, Nov 20, 2012 at 10:20 AM, David Miller wrote:
> From: Konstantin Serebryany
> Date: Tue, 20 Nov 2012 09:34:14 +0400
>
>> On Tue, Nov 20, 2012 at 9:26 AM, David Miller wrote:
>>> From: Konstantin Serebryany
>>> Date: Tue, 20 Nov 2012 09:20:29 +0400
>
Done: http://llvm.org/viewvc/llvm-project?rev=168358&view=rev
On Tue, Nov 20, 2012 at 12:19 PM, David Miller wrote:
> From: Konstantin Serebryany
> Date: Tue, 20 Nov 2012 11:41:03 +0400
>
>> Ok. Will this work?
>>
>> // Are we using 32-bit or 64-bit syscalls?
>
On Tue, Nov 20, 2012 at 5:41 PM, Peter Bergner wrote:
> On Tue, 2012-11-20 at 11:07 +0400, Konstantin Serebryany wrote:
>> I've applied your patch (with minor style and comment changes) upstream:
>> http://llvm.org/viewvc/llvm-project?view=rev&revision=168356
>> I d
On Tue, Nov 20, 2012 at 6:18 PM, Evgeniy Stepanov
wrote:
> On Tue, Nov 20, 2012 at 5:52 PM, Konstantin Serebryany
> wrote:
>>
>> On Tue, Nov 20, 2012 at 5:41 PM, Peter Bergner
>> wrote:
>> > On Tue, 2012-11-20 at 11:07 +0400, Konstantin Serebryany wrote:
&g
http://llvm.org/viewvc/llvm-project?rev=168369&view=rev
On Tue, Nov 20, 2012 at 7:12 PM, Evgeniy Stepanov
wrote:
> 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:
>>
Evgeniy, my change broke the ARM Android runs:
sanitizer_common/sanitizer_stacktrace.cc:147 "((size > count)) != (0)"
(0x0, 0x0)
Could you please take a look?
On Tue, Nov 20, 2012 at 6:01 PM, Peter Bergner wrote:
> On Tue, 2012-11-20 at 17:52 +0400, Konstantin Serebryany wrote
>> I assume we are just waiting for someone to commit this to the GCC src,
One possible value of 'someone' is kcc (me), but I *may* not be able
to do it until ~ Monday.
Other possible values of 'someone' are wmi and dvyukov
>> correct? David (Miller), were you going to do that? I'd like that
>>
On Tue, Nov 20, 2012 at 11:09 PM, David Miller wrote:
> From: Konstantin Serebryany
> Date: Tue, 20 Nov 2012 23:02:36 +0400
>
>> I really need your help to resolve this mess.
>
> I thought it was abundantly clear that the burdon falls upon the ASAN
> folks, since they are
On Tue, Nov 20, 2012 at 11:08 PM, Peter Bergner wrote:
> On Tue, 2012-11-20 at 18:18 +0400, Evgeniy Stepanov wrote:
>
>> I wonder if under some conditions we may get a different number of
>> extra frames (inlining comes to mind). What do you think of removing
>> any number of frames that belong to
On Tue, Nov 20, 2012 at 11:37 PM, David Miller wrote:
> From: Konstantin Serebryany
> Date: Tue, 20 Nov 2012 23:19:51 +0400
>
>> On Tue, Nov 20, 2012 at 11:09 PM, David Miller wrote:
>>> From: Konstantin Serebryany
>>> Date: Tue, 20 Nov 2012 23:02:36 +0400
&g
On Wed, Nov 21, 2012 at 2:50 AM, Andreas Schwab wrote:
> David Miller writes:
>
>> +// Are we using 32-bit or 64-bit syscalls?
>> +// x32 (which defines __x86_64__) has __WORDSIZE == 32
>> +// but it still needs to use 64-bit syscalls.
>> +#if defined(__x86_64__) || __WORDSIZE == 64
>
> I don't t
On Wed, Nov 21, 2012 at 12:23 PM, Andreas Schwab wrote:
> Konstantin Serebryany writes:
>
>> On Wed, Nov 21, 2012 at 2:50 AM, Andreas Schwab
>> wrote:
>>> David Miller writes:
>>>
>>>> +// Are we using 32-bit or 64-bit syscalls?
>>>
>>
>> libsanitizer is a third party library, its primary repository is not gcc.
>> If we make such change (use __LP64__ instead of __WORDSIZE), we should
>> make it upstream first.
>
> That is true, but it really should change, __WORDSIZE is a glibc private
> macro that other programs just shouldn'
On Wed, Nov 21, 2012 at 1:05 PM, Jakub Jelinek wrote:
> On Tue, Nov 20, 2012 at 11:19:33PM -0500, David Miller wrote:
>> From: David Miller
>> Date: Tue, 20 Nov 2012 21:20:40 -0500 (EST)
>>
>> > Those seem to be the only problems that need to be resolved for this
>> > feature to be fully working.
On Wed, Nov 21, 2012 at 6:20 AM, David Miller wrote:
> From: David Miller
> Date: Tue, 20 Nov 2012 14:59:10 -0500 (EST)
>
>> From: Konstantin Serebryany
>> Date: Tue, 20 Nov 2012 23:52:48 +0400
>>
>>> Please apply whatever minimal patch required to unbreak
On Wed, Nov 21, 2012 at 7:29 PM, David Miller wrote:
> From: Konstantin Serebryany
> Date: Wed, 21 Nov 2012 17:39:05 +0400
>
>> Today, kPageSize is used in several places where it is expected to be
>> a compile-time constant.
>> Even if it seems like replacing it wit
On Wed, Nov 21, 2012 at 8:05 PM, Peter Bergner wrote:
> On Wed, 2012-11-21 at 19:39 +0400, Konstantin Serebryany wrote:
>> On Wed, Nov 21, 2012 at 7:29 PM, David Miller wrote:
>> > From: Konstantin Serebryany
>> > Date: Wed, 21 Nov 2012 17:39:05 +0400
>> &g
On Wed, Nov 21, 2012 at 8:16 PM, Peter Bergner wrote:
> On Wed, 2012-11-21 at 13:46 +0400, Evgeniy Stepanov wrote:
>> Matching FP or SP also sounds good, and perhaps more reliable than
>> just popping 2 frames from the top of the stack.
>
> Agreed. Can you try my second patch that searches for th
On Wed, Nov 21, 2012 at 8:40 PM, David Miller wrote:
> From: Konstantin Serebryany
> Date: Wed, 21 Nov 2012 19:39:52 +0400
>
>> There are various other things that asan library does not support.
>
> I'm trying to understand why making the page size variable
>
On Wed, Nov 21, 2012 at 9:13 PM, Ramana Radhakrishnan wrote:
> On 11/21/12 16:27, Andrew Pinski wrote:
>>
>> On Wed, Nov 21, 2012 at 8:21 AM, Konstantin Serebryany
>> wrote:
>>>
>>> On Wed, Nov 21, 2012 at 8:05 PM, Peter Bergner
>>> wrote:
>>
On Wed, Nov 21, 2012 at 10:42 PM, H.J. Lu wrote:
> Hi,
>
> I am working on ASAN bootstrap support. I need a CPP macro
> for -fsanitize=address. I am learning toward __SANITIZE_ADDRESS__.
That would be a reasonable option
(some background: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55397)
--kc
Added to README.gcc:
The merges from upstream should be done with the aid of the merge.sh script;
it will also update the file MERGE to contain the upstream revision
we merged with.
On Wed, Nov 21, 2012 at 11:03 PM, Xinliang David Li wrote:
> How about also documenting this in README.gcc?
>
> Da
Looks good, but I guess we also need to copy the file LICENSE.TXT
--kcc
On Wed, Nov 21, 2012 at 10:44 PM, Jack Howarth wrote:
>The attached patch imports the missing mach_override/mach_override.h and
> mach_override/mach_override.c files from llvm.org's compiler-rt at
>
> r168032 | glider |
I recall that the stack trace of the offending memory access has in fact
>> three extra frames on top. I'll verify tomorrow. If so, FP/SP matching
>> solution is preferable.
>>
>> On Nov 21, 2012 9:08 PM, "Peter Bergner" wrote:
>>>
>>> On We
Looks good!
(not sure if I am a proper reviewer though)
--kcc
On Thu, Nov 22, 2012 at 3:07 PM, Jakub Jelinek wrote:
> Hi!
>
> This patch adds the no_address_safety_analysis attribute. Tested on
> x86_64-linux, ok for trunk?
>
> 2012-11-22 Jakub Jelinek
>
> PR sanitizer/55435
>
Anything else?
On Thu, Nov 22, 2012 at 6:42 AM, Konstantin Serebryany
wrote:
> Added to README.gcc:
> The merges from upstream should be done with the aid of the merge.sh script;
> it will also update the file MERGE to contain the upstream revision
> we merged with.
>
>
> On
Done, thanks!
r193743.
On Fri, Nov 23, 2012 at 2:50 AM, Xinliang David Li wrote:
> Looks fine to me.
>
> David
>
> On Thu, Nov 22, 2012 at 11:06 AM, Konstantin Serebryany
> wrote:
>> Anything else?
>>
>> On Thu, Nov 22, 2012 at 6:42 AM, Konstantin Serebryan
Looks good.
On Fri, Nov 23, 2012 at 3:27 PM, Tobias Burnus wrote:
> Konstantin Serebryany wrote:
>>
>> On Mon, Nov 19, 2012 at 10:44 PM, Tobias Burnus wrote:
>>>
>>> attached is a first draft for -faddress-sanitizer in the release notes.
>>
>> stac
s change for me.
The reports look like
#0 0x555c96f2 in ??:0
#1 0x80488d1 in ??:0
i.e. either the debug info is missing or the symbolizer script is not working.
Any suggestion?
> ).
>
> On Fri, Nov 23, 2012 at 03:03:22PM +0400, Konstantin Serebryany wrote:
> 2012-11-23 Kostya S
On Fri, Nov 23, 2012 at 4:47 PM, Jakub Jelinek wrote:
> On Fri, Nov 23, 2012 at 04:35:29PM +0400, Konstantin Serebryany wrote:
>> > Ok, provided it has been properly tested
>>
>> The upstream library is continuously tested on Linux, Mac, Windows and
>> Android
&g
On Fri, Nov 23, 2012 at 5:22 PM, Tobias Burnus wrote:
> Konstantin Serebryany wrote:
>>
>> Looks good.
>
>
> And now available at http://gcc.gnu.org/gcc-4.8/changes.html
Cool!
>
>
>>> Notes: I didn't mention Sparc, PowerPC, and Darwin
>>
&
On Fri, Nov 23, 2012 at 5:30 PM, Tobias Burnus wrote:
> Konstantin Serebryany wrote:
>>>
>>> >I think the man page should be then updated.
>>
>> man page?
>
>
> I mean gcc/doc/invoke.texi, which is available as "man gcc" and also part o
On Fri, Nov 23, 2012 at 8:07 PM, Jakub Jelinek wrote:
> On Fri, Nov 23, 2012 at 06:47:06PM +0400, Konstantin Serebryany wrote:
>> >> > Executing on host: addr2line -f -e
>> >> > /usr/local/google/kcc/gcc-build/gcc/testsuite/gcc/memcmp-1.exe
>> &g
Looks great.
(I am not an expert in the build system either, but the changes look trivial).
Thanks!
--kcc
On Fri, Nov 23, 2012 at 8:29 PM, Alexander Potapenko wrote:
> The mach_override path looks good to me. I don't have enough knowledge
> of GCC buildsystem yet to review the rest.
>
> On Fri,
On Fri, Nov 23, 2012 at 10:08 PM, H.J. Lu wrote:
> On Fri, Nov 23, 2012 at 9:38 AM, Jakub Jelinek wrote:
>> On Fri, Nov 23, 2012 at 09:23:37AM -0800, H.J. Lu wrote:
>>> This patch allocates extra 16 bytes for -fsanitize=address so that
>>> asan won't report read beyond memory buffer. It is used b
Done, r193849.
Now that the merging became 95% automated, I can do another merge upon request.
On Tue, Nov 27, 2012 at 5:53 PM, Jakub Jelinek wrote:
> On Tue, Nov 27, 2012 at 05:46:55PM +0400, Konstantin Serebryany wrote:
>> This is libsanitizer merge from upstream 168699.
>> T
On Wed, Nov 21, 2012 at 9:05 PM, Konstantin Serebryany
wrote:
> On Wed, Nov 21, 2012 at 8:40 PM, David Miller wrote:
>> From: Konstantin Serebryany
>> Date: Wed, 21 Nov 2012 19:39:52 +0400
>>
>>> There are various other things that asan library does not support.
I'd like to understand our long-term strategy wrt the asan/tsan tests in gcc.
Most of the tests we have today are not specific to the compiler and
so can potentially be used with any compiler.
The problem is the testing harness (FileCheck/gtest vs dejagnu).
I understand that using alien testing har
On Wed, Nov 28, 2012 at 2:24 PM, Jakub Jelinek wrote:
> On Wed, Nov 28, 2012 at 02:10:05PM +0400, Konstantin Serebryany wrote:
>> I'd like to understand our long-term strategy wrt the asan/tsan tests in gcc.
>> Most of the tests we have today are not specific to the co
PM +0400, Konstantin Serebryany wrote:
>> I fully agree about "minimal testsuite".
>> But, for example, porting the asan's gtest test (2+ KLOC) to another
>> harness is probably too much.
>
> Depends on how significant changes to the test body are actually nee
On Wed, Nov 28, 2012 at 3:24 PM, Jakub Jelinek wrote:
> On Wed, Nov 28, 2012 at 12:03:27PM +0100, Jakub Jelinek wrote:
>> Then the test would be run once without ASAN_DIE_IF in environment (or =0),
>> that would produce output full of
>> EXPECT_DEATH1 AddressSanitizer:.*heap-use-after-free EXPECT_
e(address_sanitizer) || defined(__SANITIZE_ADDRESS__)
this is upstreamable
+#ifdef __GNUC__
+# define break_optimization(arg) __asm__ __volatile__ ("" : : "r"
(arg) : "memory")
+#endif
+
That's a nice piece of magic, let me use this too.
Cool!
--kcc
On Fri, Nov 30, 2012 at 1
I've upstreamed most of your changes, please take a look.
Looks like we will be able to use libsanitizer/merge.sh to update the
test code as well.
On Fri, Nov 30, 2012 at 2:14 PM, Jakub Jelinek wrote:
> On Fri, Nov 30, 2012 at 01:32:52PM +0400, Konstantin Serebryany wrote:
>> Id
On Sun, Dec 2, 2012 at 10:21 AM, Alexander Potapenko wrote:
> Hi Jack,
>
> IIUC the wrappers for dispatch_async_f, dispatch_sync_f and other
> dispatch_smth_f do not need blocks support in the compiler, since
> regular functions are passed into them. So you may want to add the
> dynamic intercepto
Looks good.
Long term the fact that we need to completely fork these tests makes me sad.
I'd really love to see a way to make them compiler-neutral.
All we need is to mock FileCheck (or put it into libsanitizer/aux somehow).
Ideas?
--kcc
On Sat, Dec 1, 2012 at 12:35 AM, Wei Mi wrote:
> Thanks
Hi Jack,
May I ask you to attach the complete patch (with ChangeLog entries and
regenerated files, if possible)?
May I also ask you to update libsanitizer/merge.sh to handle
libsanitizer/asan/dynamic ?
Assuming the files from upstream are copied verbatim (are they?), the
patch is ok.
Still, please
On Mon, Dec 3, 2012 at 1:18 PM, Jakub Jelinek wrote:
> On Mon, Dec 03, 2012 at 11:06:48AM +0400, Konstantin Serebryany wrote:
>> This patch copies the asan tests almost, but not quite, verbatim from
>> upstream.
>> Since the patch is not in attachment (and gmail messes up wi
On Mon, Dec 3, 2012 at 3:05 PM, Jakub Jelinek wrote:
> On Mon, Dec 03, 2012 at 01:51:50PM +0400, Konstantin Serebryany wrote:
>> > I'm attaching the diff for asan_test.cc from llvm anyway.
>> >
>> >> I see #ifdef ASAN_AVOID_EXPENSIVE_TESTS, which I don'
On Mon, Dec 3, 2012 at 10:02 PM, David Miller wrote:
> From: Konstantin Serebryany
> Date: Tue, 27 Nov 2012 18:12:00 +0400
>
>> On Wed, Nov 21, 2012 at 9:05 PM, Konstantin Serebryany
>> wrote:
>>> On Wed, Nov 21, 2012 at 8:40 PM, David Miller wrote:
>>>&
On Mon, Dec 3, 2012 at 10:29 PM, David Miller wrote:
> From: Konstantin Serebryany
> Date: Mon, 3 Dec 2012 22:18:56 +0400
>
>> On Mon, Dec 3, 2012 at 10:02 PM, David Miller wrote:
>>> The only changes to libsantizier is to put __sparc__ checks where
>>> __pow
On Mon, Dec 3, 2012 at 10:31 PM, Jakub Jelinek wrote:
> On Mon, Dec 03, 2012 at 10:18:56PM +0400, Konstantin Serebryany wrote:
>> The LLVM implementation always used 32-byte alignment for stack redzones.
>> I never actually did any performance checking on x86 (32-byte aligned
>&
On Mon, Dec 3, 2012 at 10:37 PM, David Miller wrote:
> From: Konstantin Serebryany
> Date: Mon, 3 Dec 2012 22:33:12 +0400
>
>> On Mon, Dec 3, 2012 at 10:29 PM, David Miller wrote:
>>> We could also add a __sparc__ block to sanitizer_stacktrace.cc:patch_pc().
>>>
On Mon, Dec 3, 2012 at 10:32 PM, Wei Mi wrote:
> Hi,
>
> Jakub, thank you for your so detailed comments! I will fix them
> according to your comments. About the lto options, llvm test does't
> include it too so I skipped it in torture options. Is it because most
> cases we only use asan under O1/O
012 at 10:41 PM, Jakub Jelinek wrote:
> On Mon, Dec 03, 2012 at 10:18:56PM +0400, Konstantin Serebryany wrote:
>> The LLVM implementation always used 32-byte alignment for stack redzones.
>> I never actually did any performance checking on x86 (32-byte aligned
>> vs 8-byte ali
r194120.
I've tested it on Linux, but not on Mac.
On Tue, Dec 4, 2012 at 6:44 AM, Alexander Potapenko wrote:
> I've added MISSING_BLOCKS_SUPPORT to LLVM compiler-rt in r169206.
> The rest of your change looks good to me as well.
>
> On Mon, Dec 3, 2012 at 6:33 PM, Alexander Potapenko wrote:
>> J
On Tue, Dec 4, 2012 at 7:03 PM, Jack Howarth wrote:
> On Tue, Dec 04, 2012 at 11:02:01AM +0400, Konstantin Serebryany wrote:
>> r194120.
>> I've tested it on Linux, but not on Mac.
>
> kcc,
>Tested at r194135 on x86_64-apple-darwin12. Thanks for the commit.
>
On Wed, Dec 5, 2012 at 3:39 PM, Jakub Jelinek wrote:
> Hi!
>
> Another problem from the compiler side when working on the asan testsuite
> is that at higher -O* levels the __asan_report_* noreturn calls are
> cross-jumped, but the library relies on their locus to print accurrate
> locations when s
On Wed, Dec 5, 2012 at 4:43 PM, Jakub Jelinek wrote:
> On Wed, Dec 05, 2012 at 02:59:48PM +0400, Konstantin Serebryany wrote:
>> The attached patch is the libsanitizer mege from upstream r169371.
>> Automatically generated by libsanitizer/merge.sh
>> Tested with
>>
Yea, sorry.
I've noticed this upstream and committed a fix there.
Feel free to remove these lines (or wait until I do another merge
first thing tomorrow).
--kcc
On Wed, Dec 5, 2012 at 7:13 PM, Dominique Dhumieres wrote:
>> r194221
>
> It breaks bootstrap on x86_64-apple-darwin10:
>
> /opt/gcc/bu
On Wed, Dec 5, 2012 at 7:43 PM, Jakub Jelinek wrote:
> Hi!
>
> On Wed, Dec 05, 2012 at 04:06:51PM +0100, Jakub Jelinek wrote:
>> FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_GlobalStringConstTest
>> Ident(p[15]) execution test
>
> So, this one fails because we don't instrument string lite
On Wed, Dec 5, 2012 at 9:46 PM, Jakub Jelinek wrote:
> On Wed, Dec 05, 2012 at 09:42:08PM +0400, Konstantin Serebryany wrote:
>> On Wed, Dec 5, 2012 at 7:43 PM, Jakub Jelinek wrote:
>> > So, this one fails because we don't instrument string literals, in GCC
>> &g
Hi,
The attached patch is the libsanitizer merge from upstream r169392.
Among other things It fixes the darwin build.
Automatically generated by libsanitizer/merge.sh
Tested with
rm -rf */{*/,}libsanitizer \
&& make -j 50 \
&& make -C gcc check-g{cc,++}
RUNTESTFLAGS='--target_board=unix\{-m32
On Thu, Dec 6, 2012 at 10:38 AM, Alexander Potapenko wrote:
> In fact nothing prevents GCC from having a linkable static ASan runtime.
Except (as Alex mentions) we are not going to support it.
I'll apply this patch later (~today).
--kcc
> The reason for the static library being unusable is not
Any objections?
On Wed, Dec 5, 2012 at 10:15 PM, Konstantin Serebryany
wrote:
> Hi,
>
> The attached patch is the libsanitizer merge from upstream r169392.
> Among other things It fixes the darwin build.
>
> Automatically generated by libsanitizer/merge.sh
>
done, 194255. Thanks!
--kcc
On Thu, Dec 6, 2012 at 6:24 PM, Jakub Jelinek wrote:
> On Thu, Dec 06, 2012 at 06:17:51PM +0400, Konstantin Serebryany wrote:
>> Any objections?
>
> This is fine.
>
> Jakub
Done, r194257.
On Thu, Dec 6, 2012 at 12:04 PM, Konstantin Serebryany
wrote:
> On Thu, Dec 6, 2012 at 10:38 AM, Alexander Potapenko
> wrote:
>> In fact nothing prevents GCC from having a linkable static ASan runtime.
>
> Except (as Alex mentions) we are not going to suppor
+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
On Mon, May 6, 2013 at 10:52 PM, Christophe Lyon
wrote:
> Hi,
>
> Here is a 2nd
when on ARM).
>
> A white line before #if defined(__powerpc__) would help readability :-)
>
> Forget that part.
>
> Thanks,
>
> Christophe.
>
>
>
>
> On 7 May 2013 09:44, Evgeniy Stepanov wrote:
>> On Tue, May 7, 2013 at 9:33 AM, Konstant
On Fri, May 31, 2013 at 6:49 PM, Jack Howarth wrote:
> On Fri, May 31, 2013 at 04:42:21PM +0200, Christophe Lyon wrote:
>> Hi,
>>
>> I'd like to backport libsanitizer commit #182922:
>> Index: sanitizer_common/sanitizer_linux.cc
>> ==
On Wed, Jun 5, 2013 at 6:40 AM, David Malcolm wrote:
> The table of struct tsan_map_atomic within tsan.c is never modified, so
> it can be marked as const.
>
> Successfully bootstrapped on x86_64-unknown-linux-gnu (using
> gcc-4.7.2-2.fc17.x86_64).
>
> OK for trunk?
Looks good, thanks.
--kcc
>
On Wed, Jun 5, 2013 at 11:40 PM, Andrew Pinski wrote:
> On Wed, Jun 5, 2013 at 12:23 PM, Jakub Jelinek wrote:
>> On Wed, Jun 05, 2013 at 11:44:07AM -0700, Andrew Pinski wrote:
>>> On Wed, Jun 5, 2013 at 10:57 AM, Marek Polacek wrote:
>>> > Comments, please?
>>> I think it might be better to do h
On Thu, Jun 6, 2013 at 12:26 PM, Andrew Pinski wrote:
> On Thu, Jun 6, 2013 at 1:21 AM, Jakub Jelinek wrote:
>> On Thu, Jun 06, 2013 at 11:46:19AM +0400, Konstantin Serebryany wrote:
>>> If we are going to import the ubsan run-time from LLVM's
>>> projects/compil
+rich...@metafoo.co.uk
On Thu, Jun 6, 2013 at 12:21 PM, Jakub Jelinek wrote:
> On Thu, Jun 06, 2013 at 11:46:19AM +0400, Konstantin Serebryany wrote:
>> If we are going to import the ubsan run-time from LLVM's
>> projects/compiler-rt/lib/ubsan,
>> we may also need
On Thu, Jun 6, 2013 at 12:44 PM, Jakub Jelinek wrote:
> On Thu, Jun 06, 2013 at 12:41:56PM +0400, Konstantin Serebryany wrote:
>> As for libstdc++, I completely agree, we don't want to depend on it,
>> and we don't.
>
> ubsan actu
On Thu, Jun 6, 2013 at 12:59 PM, Jakub Jelinek wrote:
> On Thu, Jun 06, 2013 at 12:55:17PM +0400, Konstantin Serebryany wrote:
>> > ubsan actually needs
>> > U _ZTIN10__cxxabiv117__class_type_infoE@@CXXABI_1.3
>> > U _ZTIN10__c
- one wrong e-mail
On Mon, Sep 22, 2014 at 11:44 AM, Konstantin Serebryany
wrote:
> re-sending with the patch compressed:
>
> === gcc/testsuite/ChangeLog
> 2014-09-22 Kostya Serebryany
>
> Update to match the changed asan API.
> * asan.
On Tue, Sep 23, 2014 at 7:16 AM, Jakub Jelinek wrote:
> On Mon, Sep 22, 2014 at 11:44:57AM -0700, Konstantin Serebryany wrote:
>> re-sending with the patch compressed:
>>
>> === gcc/testsuite/ChangeLog
>> 2014-09-22 Kostya Serebryany
>>
>>
+Alexey Samsonov
On Mon, Sep 29, 2014 at 10:43 AM, Jakub Jelinek wrote:
> On Mon, Sep 29, 2014 at 09:21:11PM +0400, Yury Gribov wrote:
>> >>This patch enables -fsanitize-recover for KASan by default. This causes
>> >>KASan to continue execution after error in case of inline
>> >>instrumentation.
101 - 200 of 284 matches
Mail list logo
