On Mon, Jan 19, 2015 at 11:09 PM, Bernd Edlinger
wrote:
>
> Hi,
>
> On Mon, 19 Jan 2015 18:49:21, Konstantin Serebryany wrote:
>>
>> [text-only]
>>
>> On Mon, Jan 19, 2015 at 7:42 AM, Mike Stump wrote:
>>> On Jan 19, 2015, at 12:43 AM, Dmitry Vyuko
[text-only]
On Mon, Jan 19, 2015 at 7:42 AM, Mike Stump wrote:
> On Jan 19, 2015, at 12:43 AM, Dmitry Vyukov wrote:
>> I can't really make my mind on this. I would mildly prefer sleep's (if
>> they work reliably!).
>
> Let me state it more forcefully.
You don't have to convince us here.
I'd love
sources in GCC is potentially
leading to large delays in the merge process:
imagine that some of the code upstream gets incompatible with
-std=gnu++ for whatever reason.
--kcc
On Fri, Nov 14, 2014 at 11:35 AM, Andrew Pinski wrote:
> On Fri, Nov 14, 2014 at 11:29 AM, Konstantin Serebryany
>
+gcc-patches
On Fri, Nov 14, 2014 at 11:26 AM, Konstantin Serebryany
wrote:
> I am opposed to this change.
> Upstream code builds with -std=c++11.
> Building this code here with another set of options is a time bomb.
>
> On Fri, Nov 14, 2014 at 6:23 AM, wrote:
>> Author:
+eugenis (what kind of testing on ARM are we doing upstream?)
On Fri, Nov 14, 2014 at 7:44 AM, Christophe Lyon
wrote:
> On 14 November 2014 11:38, Christophe Lyon wrote:
>> On 13 November 2014 21:44, Konstantin Serebryany
>> wrote:
>>> On Thu, Nov 13, 2014 at 1:16
I am not sure I understand the problem,
but whatever the problem is I am against using -std=gnu++ as this will
be a different flag combination from what we have upstream.
On Fri, Nov 14, 2014 at 8:50 AM, Konstantin Serebryany
wrote:
> Let's continue the discussion there, we can do anoth
4, Konstantin Serebryany
> wrote:
>> On Thu, Nov 13, 2014 at 1:16 AM, Jakub Jelinek wrote:
>>> On Wed, Nov 12, 2014 at 05:35:48PM -0800, Konstantin Serebryany wrote:
>>>> Here is one more merge of libsanitizer (last one was in Sept).
>>>>
&g
On Thu, Nov 13, 2014 at 1:16 AM, Jakub Jelinek wrote:
> On Wed, Nov 12, 2014 at 05:35:48PM -0800, Konstantin Serebryany wrote:
>> Here is one more merge of libsanitizer (last one was in Sept).
>>
>> Tested on x86_64 Ubuntu 14.04 like this:
>> rm -rf */{*/,}libsanitizer
Hi,
Here is one more merge of libsanitizer (last one was in Sept).
Tested on x86_64 Ubuntu 14.04 like this:
rm -rf */{*/,}libsanitizer && make -j 50
make -j 40 -C gcc check-g{cc,++}
RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} asan.exp' && \
make -j 40 -C gcc check-g{cc,++}
RUNTESTFLAGS='--targ
On Mon, Sep 29, 2014 at 6:05 PM, Alexey Samsonov wrote:
> On Mon, Sep 29, 2014 at 5:24 PM, Konstantin Serebryany
> wrote:
>>
>> On Mon, Sep 29, 2014 at 4:26 PM, Alexey Samsonov wrote:
>> > On Mon, Sep 29, 2014 at 4:17 PM, Jakub Jelinek wrote:
>> >> O
On Mon, Sep 29, 2014 at 4:26 PM, Alexey Samsonov wrote:
> On Mon, Sep 29, 2014 at 4:17 PM, Jakub Jelinek wrote:
>> On Mon, Sep 29, 2014 at 03:36:20PM -0700, Alexey Samsonov wrote:
>>> -fasan-recover doesn't look like a good idea - for instance, in Clang, we
>>> never use "?san"
>>> in flag names,
+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.
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
>>
>>
- 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.
[replying text only]
Hi Chen,
as per https://code.google.com/p/address-sanitizer/wiki/HowToContribute
all changes to libsanitizer, even such simple ones,
have to go through the LLVM tree first.
But, what makes you think there is a bug here?
The comment in sanitizer_common/sanitizer_common.h says:
.
int bar();
int foo(unsigned i) {
int a[3] = {bar(), bar(), bar()};
return a[i % 3];
}
--kcc
On Tue, Aug 19, 2014 at 4:42 PM, Konstantin Serebryany
wrote:
> On Mon, Aug 18, 2014 at 1:05 PM, Yuri Gribov wrote:
>> On Fri, Aug 15, 2014 at 10:34 PM, Konstantin Serebryany
>> wrote:
On Mon, Aug 18, 2014 at 1:05 PM, Yuri Gribov wrote:
> On Fri, Aug 15, 2014 at 10:34 PM, Konstantin Serebryany
> wrote:
>> If this is -O1 or higher, then most (but not all) of your cases
>> *should* be optimized by the compiler before asan kicks in.
>
> You mean hoist
On Thu, Aug 14, 2014 at 11:55 PM, Yuri Gribov wrote:
> On Thu, Aug 14, 2014 at 8:53 PM, Konstantin Serebryany
> wrote:
>> In order for your work to be generally useful, I'd ask several things:
>> - Update
>> https://code.google.com/p/address-sanitizer/wiki/Com
Indeed, thanks for working on this.
We've been wanting such optimization phase from day one, but never got
to implementing it (except for a few simple ones).
https://code.google.com/p/address-sanitizer/wiki/CompileTimeOptimizations
There have been several attempts outside of our team to do such
opt
On Fri, Jul 4, 2014 at 4:38 PM, Rainer Orth
wrote:
> Hi Konstantin,
>
>> All contributions to libsanitizer should go via LLVM repository.
>> See https://code.google.com/p/address-sanitizer/wiki/HowToContribute
>> The smaller the patches the faster they will come through.
>
> ok. I'll see how to
Hi Rainer,
All contributions to libsanitizer should go via LLVM repository.
See https://code.google.com/p/address-sanitizer/wiki/HowToContribute
The smaller the patches the faster they will come through.
If you can set up a public build bot it will *immensely* simplify many things.
(see more below
On Wed, Jun 11, 2014 at 2:28 PM, Paolo Carlini wrote:
> Hi,
>
> On 05/22/2014 09:02 PM, Jakub Jelinek wrote:
>>
>> In file included from
>> ../../../../trunk/libsanitizer/asan/asan_interceptors.cc:147:0:
>>
>> ../../../../trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:
>> In
On Tue, Jun 3, 2014 at 1:33 PM, Yury Gribov wrote:
>> Any reason why the BUILT_IN_* names so differ from the actual function
>> names? I.e. why not use BUILT_IN_ASAN_{LOAD,STORE}{1,2,4,8,16,N}
>> (no underscore before N, no CHECK_)?
>
>
> Makes sense.
>
>> Wouldn't it be better to do
>> ...
>>
>>
On Thu, May 29, 2014 at 6:29 PM, Jonathan Wakely wrote:
> On 26/05/14 19:19 +0400, Konstantin Serebryany wrote:
>>>
>>> It does look useful but I'm concerned about a proliferation of
>>> container checks, we already have the libstdc++ Debug Mode
>>> and
Committed as r210012, please don't forget to add llvm-commits to CC
next time (I did not see the message)
Thanks!
On Mon, Jun 2, 2014 at 9:57 AM, Yury Gribov wrote:
>>> There was some discussion on what to do, but has there been a decision on
>>> how to fix this yet? Or is it fixed upstream and
On Sat, May 31, 2014 at 11:53 PM, Peter Bergner wrote:
> On Fri, 2014-05-30 at 15:49 +0200, Jakub Jelinek wrote:
>> On Fri, May 30, 2014 at 08:09:22AM -0500, Peter Bergner wrote:
>> > On Thu, 2014-05-29 at 14:07 -0500, Peter Bergner wrote:
>> > > On Wed, 2014-05-28 at 09:36 +0200, Thomas Schwinge
Thanks Jakub!
Looks like there is not rush with another merge now.
--kcc
On Fri, May 30, 2014 at 5:49 PM, Jakub Jelinek wrote:
> On Fri, May 30, 2014 at 08:09:22AM -0500, Peter Bergner wrote:
>> On Thu, 2014-05-29 at 14:07 -0500, Peter Bergner wrote:
>> > On Wed, 2014-05-28 at 09:36 +0200, Thoma
On Wed, May 28, 2014 at 5:33 PM, Marat Zakirov wrote:
> Hi all,
>
> Here's a patch for optional Asan instrumentation of inline assembly.
>
> This version scans gimple for GIMPLE_ASMs and performs usual instrumentation
> of arguments with memory constraints ("m", "o", etc.) with fixed size.
>
> Ins
Dmitry,
You've introduced atomic_uint64_t stats_[AllocatorStatCount]; in
http://llvm.org/viewvc/llvm-project?view=revision&revision=173332
Do you mind to change it to atomic_uintptr_t?
There is of course a chance of overflow on 32-bit arch (the number of
mallocs in a process may easily go over 2^
On Tue, May 27, 2014 at 9:53 PM, Mike Stump wrote:
>
> On May 26, 2014, at 10:13 PM, Konstantin Serebryany
> wrote:
>>> On Mon, 2014-05-26 at 10:36 +0400, Konstantin Serebryany wrote:
>>>> Because this is my default reply to any such case. :)
>>>
>&g
On Tue, May 27, 2014 at 9:40 AM, Yury Gribov wrote:
>> - using instrumentation via calls adds extra 1.5x-2.x slowdown
>
> On x64.
Interesting. can you share your ARM numbers?
>
>
>> - it would be nice to have the name prefix configurable from command
>> line (${PREFIX}_load1 instead of __asan_lo
my 2c
- using instrumentation via calls adds extra 1.5x-2.x slowdown
- it indeed saves code size
- in LLVM this was done mostly to overcome the compile time problem on
huge functions
- in GCC we will indeed need this for kasan
(https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKe
problem, in particular the allocator now newly
>> > relying on
>> > 2 x word size atomics which is definitely non-portable, I don't see why
>> > the answer
>> > to that should be disable your port or build a buildbot.
>
> Right, the ppc32 results definitel
On Mon, May 26, 2014 at 6:12 PM, Jonathan Wakely wrote:
> On 26/05/14 17:40 +0400, Konstantin Serebryany wrote:
>>
>> Would you consider a patch similar to [4] for libstdc++ trunk?
>> If yes, any comments on the patch?
>
>
> + // When sanitizer annotataions are
Hello,
Some of std::vector misuses are very hard to find with internal STL checks
or using external tools (such as Valgrind or AddressSanitizer [1]).
Example:
std::vector v(4);
v.reserve(8);
int *p = v.data();
p[6] = 0; // BOOM
We call these bugs "container overflow" [2,6] and we've deve
On Mon, May 26, 2014 at 2:53 PM, Arseny Solokha wrote:
> Recent changes in GetPcSpBp() (libsanitizer/asan/asan_linux.cc) made it
> impossible to build 4.10.0-alpha20140525 snapshot for powerpc targets. The
> proposed patch disables building libsanitizer for powerpc*-*-linux* in
> addition
> to al
at offset 47 partially overflows
this variable
[64, 68) 'v'
[80, 88) 'p'
[112, 116) 'w'
Apparently, this "unknown-crash" needs to be fixed.
Give me some time (may not have it this week though).
--kcc
On Mon, May 26, 2014 at 12:57 PM, Jakub Jel
On Fri, May 23, 2014 at 8:45 PM, Jakub Jelinek wrote:
> On Fri, May 23, 2014 at 04:11:48PM +0400, Konstantin Serebryany wrote:
>> >> 2) it doesn't still deal with unaligned power of two accesses properly,
>> >>but neither does llvm (at least not 3.4). Am not
On Mon, May 26, 2014 at 9:57 AM, Jakub Jelinek wrote:
> On Mon, May 26, 2014 at 08:57:11AM +0400, Konstantin Serebryany wrote:
>> Last time I tried, asan did not work on ppc32 for a large number of
>> different reasons.
>
> ???
> Comparing my 4.9.0 ppc/ppc64 testr
Hi Peter,
Last time I tried, asan did not work on ppc32 for a large number of
different reasons.
In upstream build system ppc32 is simply disabled, so imho it should
be also disabled in the GCC build.
If there is enough interest in ppc32, please work with up on fixing
upstream and enabling the bui
On Fri, May 23, 2014 at 6:35 PM, Konstantin Serebryany
wrote:
> On Fri, May 23, 2014 at 6:28 PM, Jakub Jelinek wrote:
>> On Fri, May 23, 2014 at 04:19:00PM +0200, Marek Polacek wrote:
>>> This is the latest patch for -fsanitize=float-cast-overflow. Since last
>>> ver
On Fri, May 23, 2014 at 6:28 PM, Jakub Jelinek wrote:
> On Fri, May 23, 2014 at 04:19:00PM +0200, Marek Polacek wrote:
>> This is the latest patch for -fsanitize=float-cast-overflow. Since last
>> version it:
>> - adds tons of tests written by Jakub;
>> - patches libubsan so it can handle 96-bit
On Fri, May 23, 2014 at 6:12 PM, Konstantin Serebryany
wrote:
> On Fri, May 23, 2014 at 6:11 PM, Kugan
> wrote:
>> On 24/05/14 00:06, Christophe Lyon wrote:
>>> Hi,
>>> Since merge from upstream r209283 (210743 in GCC), my build fails on
>>> ARM, beca
On Fri, May 23, 2014 at 6:11 PM, Kugan
wrote:
> On 24/05/14 00:06, 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 this expected?
> I also have the same issue. I had to build glibc with
> --enable-o
On Fri, May 23, 2014 at 5:41 PM, Marek Polacek wrote:
> On Mon, May 12, 2014 at 03:20:37PM +0400, Konstantin Serebryany wrote:
>> 5 months' worth of changes may break any platform we are not testing
>> ourselves
>> (that includes Ubuntu 12.04, 13.10, 14.04, Mac 10
>> 2) it doesn't still deal with unaligned power of two accesses properly,
>>but neither does llvm (at least not 3.4). Am not talking about
>>undefined behavior cases where the compiler isn't told the access
>>is misaligned, but e.g. when accessing struct S { int x; }
>>__attribute
On Fri, May 23, 2014 at 11:56 AM, Ramana Radhakrishnan
wrote:
> On 05/23/14 08:50, Yury Gribov wrote:
>>
>> > 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 onc
On Fri, May 23, 2014 at 11:32 AM, Ramana Radhakrishnan
wrote:
> On Thu, May 22, 2014 at 7:31 AM, Konstantin Serebryany
> wrote:
>> On Wed, May 21, 2014 at 11:43 PM, Jakub Jelinek wrote:
>>> On Wed, May 21, 2014 at 04:09:19PM +0400, Konstantin Serebryany wrote:
>>>
On Fri, May 23, 2014 at 11:20 AM, Yury Gribov wrote:
> 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
Yuri, this comes from yours
http://llvm.org/viewvc/llvm-project?view=revision&revision=205308
Could you please take a look?
On Thu, May 22, 2014 at 11:54 PM, Jakub Jelinek wrote:
> On Thu, May 22, 2014 at 09:43:01PM +0200, Paolo Carlini wrote:
>> Hi,
>>
>> On 05/22/2014 09:15 PM, Jakub Jelinek wr
>
>> > 3) there is still a failure for -m32:
>> > FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_UAF_long_double
>> > Ident(p)[12] = 0 output pattern test
>> > Output should match: WRITE of size 1[06]
>> > FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_UAF_long_double
>> > Ident(p)[0]
On Thu, May 22, 2014 at 6:07 PM, Jakub Jelinek wrote:
> On Thu, May 22, 2014 at 04:06:21PM +0400, Konstantin Serebryany wrote:
>> Not really recently... (Feb 2013)
>> http://llvm.org/viewvc/llvm-project?rev=175507&view=rev
>
> Ah, wasn't aware of that.
>
&
Oops, ignore that. Forgot -C gcc
On Thu, May 22, 2014 at 4:49 PM, Konstantin Serebryany
wrote:
> On Thu, May 22, 2014 at 3:03 PM, Jakub Jelinek wrote:
>> On Thu, May 22, 2014 at 02:26:19PM +0400, Konstantin Serebryany wrote:
>>> >> >> FAIL: c-c++-common/asan/asan
On Thu, May 22, 2014 at 3:03 PM, Jakub Jelinek wrote:
> On Thu, May 22, 2014 at 02:26:19PM +0400, Konstantin Serebryany wrote:
>> >> >> FAIL: c-c++-common/asan/asan-interface-1.c -O0 execution test
>> >> >Is that before or after r210743?
>
> Can
On Thu, May 22, 2014 at 3:43 PM, Jakub Jelinek wrote:
> On Thu, May 22, 2014 at 01:03:48PM +0200, Jakub Jelinek wrote:
>> There are various other changes to asan_test.cc, so guess some work is
>> needed on that.
>
> Ok, tried to merge also g++.dg/asan from the same revision as you've merged
> lib
What is the exact command are you running?
On Thu, May 22, 2014 at 1:47 PM, Jakub Jelinek wrote:
> On Thu, May 22, 2014 at 11:44:06AM +0200, Paolo Carlini wrote:
>> On 22 maggio 2014 11:05:31 CEST, Konstantin Serebryany
>> wrote:
>> >On Thu, May 22, 2014 at 12:54 PM,
On Thu, May 22, 2014 at 12:54 PM, Paolo Carlini
wrote:
> .. sorry, I didn't follow the whole thread, but today I'm seeing loads of
> failures when testing C++ on x86_64-linux, beginning with:
>
> FAIL: c-c++-common/asan/asan-interface-1.c -O0 execution test
Is that before or after r210743?
> FAI
On Wed, May 21, 2014 at 11:43 PM, Jakub Jelinek wrote:
> On Wed, May 21, 2014 at 04:09:19PM +0400, Konstantin Serebryany wrote:
>> A new patch based on r209283.
>> This one has the H.J.'s patches for x32.
>
> Ok for trunk then. But please help the ppc*/arm*/sparc* m
On Thu, May 15, 2014 at 12:07 PM, Andrew Pinski wrote:
> On Thu, May 15, 2014 at 1:05 AM, Konstantin Serebryany
> wrote:
>> H.J.,
>> Thanks for the patches. Please (re)send them to llvm-commits,
>> otherwise I can not accept them.
>
>
> I think this is bogus
>
> I think this argument is bogus. Please do one build system and
> support it. Simple makefile and some scripts seems simple to support
> so you don't need anything extra.
Would be glad to. One (but not the only) prerequisite for that GCC
exports libsanitizer
as "svn external" and uses our cm
H.J.,
Thanks for the patches. Please (re)send them to llvm-commits,
otherwise I can not accept them.
--kcc
On Wed, May 14, 2014 at 2:31 AM, H.J. Lu wrote:
> On Tue, May 13, 2014 at 2:02 AM, Konstantin Serebryany
> wrote:
>> New patch attached.
>> It is based on r20
On Thu, May 15, 2014 at 9:28 AM, Yury Gribov wrote:
> 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
&g
On Wed, May 14, 2014 at 11:47 AM, Yury Gribov wrote:
> 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 co
On Wed, May 14, 2014 at 9:18 AM, Yury Gribov wrote:
> 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 ta
Shouldn't we just install the entire include/sanitizer directory?
(And thanks for doing this!!)
On Tue, May 13, 2014 at 8:13 PM, Yury Gribov wrote:
> Hi,
>
> Asan and Tsan allow sanitized applications to tweak runtime behavior via API
> defined in headers in libsanitizer/include/sanitizer. This
[plain text]
On Wed, May 14, 2014 at 2:42 AM, Andrew Pinski wrote:
> On Mon, May 12, 2014 at 4:20 AM, Konstantin Serebryany
> wrote:
>> This is the first libsanitizer merge in 4.10 (the last merge was in
>> December 2013).
>>
>> Tested on Ubuntu 12.04 like this:
>> other than by following the standard process because this will violate
>> the LLVM developer policy.
>
> Which says what?
http://llvm.org/docs/DeveloperPolicy.html#making-and-submitting-a-patch
"Once your patch is ready, submit it by emailing it to the appropriate
project’s commit mailing list
On Tue, May 13, 2014 at 12:05 PM, wrote:
>
>
>> On May 13, 2014, at 12:59 AM, Konstantin Serebryany
>> wrote:
>>
>> I've committed this upstream and will include it into my next updated patch:
>>
>> +#if defined(__x86_64__) && !de
PM, H.J. Lu wrote:
> On Mon, May 12, 2014 at 4:20 AM, Konstantin Serebryany
> wrote:
>> This is the first libsanitizer merge in 4.10 (the last merge was in
>> December 2013).
>>
>> Tested on Ubuntu 12.04 like this:
>> rm -rf */{*/,}libsanitizer &&
On Mon, May 12, 2014 at 7:36 PM, Yury Gribov wrote:
> 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,
Gener
Thanks! May I ask you to contribute the patch upstream?
https://code.google.com/p/address-sanitizer/wiki/HowToContribute
On Mon, May 12, 2014 at 7:19 PM, Maxim Ostapenko
wrote:
> Hi,
>
> I see a couple of errors when building for arm-linux-gnueabi (host is x86_64
> Ubuntu 12.04 LTS, host compiler
Thanks. Let's move the discussion there.
On Wed, Apr 23, 2014 at 12:46 PM, Bernhard Reutner-Fischer
wrote:
> On 17 April 2014 19:01, Konstantin Serebryany
> wrote:
>> On Thu, Apr 17, 2014 at 8:45 PM, Bernhard Reutner-Fischer
>> wrote:
>>> On 17 April 201
On Thu, Apr 17, 2014 at 8:45 PM, Bernhard Reutner-Fischer
wrote:
> On 17 April 2014 16:51:23 Konstantin Serebryany
> wrote:
>
>> On Thu, Apr 17, 2014 at 6:27 PM, Bernhard Reutner-Fischer
>> wrote:
>> > On 17 April 2014 16:07, Konstantin Serebryany
>> >
On Thu, Apr 17, 2014 at 6:27 PM, Bernhard Reutner-Fischer
wrote:
> On 17 April 2014 16:07, Konstantin Serebryany
> wrote:
>> Hi,
>>
>> If you are trying to modify the libsanitizer files, please read here:
>> https://code.google.com/p/address-sanitizer/wiki/HowToCont
Hi,
If you are trying to modify the libsanitizer files, please read here:
https://code.google.com/p/address-sanitizer/wiki/HowToContribute
--kcc
On Thu, Apr 17, 2014 at 5:49 PM, Bernhard Reutner-Fischer
wrote:
> Conditionalize usage of dlvsym(), nanosleep(), usleep();
> Conditionalize layout of
On Thu, Feb 20, 2014 at 4:34 PM, Jakub Jelinek wrote:
> On Thu, Feb 20, 2014 at 01:15:37PM +0100, Jose E. Marchesi wrote:
>> Yesterday I fetched and built the latest llvm/compiler-rt in sparc64. I
>> could not manage (in a reasonable time) to get the stuff in
>> compiler-rt/lib/sanitizer_common a
>
> At this point I would suggest to either apply my patch to gcc's
> libsanitizer to fix the sparc build
Please don't.
The "merge" is actually not a merge, it is a simple copy of LLVM
sources over the GCC sources,
no *merging* is ever expected to happen.
> until next merge[1] or disable
> buildin
On Tue, Feb 18, 2014 at 10:00 PM, Jakub Jelinek wrote:
>
> On Tue, Feb 18, 2014 at 06:55:51PM +0100, Jose E. Marchesi wrote:
> > This patch fixes builds with --enable-sanitizer, which seems to be the
> > default for sparc now.
> >
> > Build tested in a sparc64-*-linux-gnu system with linux 3.8.13
I've started a separate topic about flaky tsan tests here:
https://groups.google.com/forum/#!topic/thread-sanitizer/KIok3F_b1oI
--kcc
On Fri, Jan 10, 2014 at 7:20 PM, Jakub Jelinek wrote:
> On Fri, Jan 10, 2014 at 03:50:33PM +0400, Maxim Ostapenko wrote:
>> On Fri, Jan 10, 2014 at 10:39 AM, Jaku
On Thu, Jan 9, 2014 at 5:57 PM, Jakub Jelinek wrote:
> On Thu, Jan 09, 2014 at 05:51:05PM +0400, Konstantin Serebryany wrote:
>> On Tue, Dec 10, 2013 at 3:38 PM, Jakub Jelinek wrote:
>> > On Fri, Dec 06, 2013 at 06:40:52AM -0800, Ian Lance Taylor wrote:
>> >> The
On Tue, Dec 10, 2013 at 3:38 PM, Jakub Jelinek wrote:
> On Fri, Dec 06, 2013 at 06:40:52AM -0800, Ian Lance Taylor wrote:
>> There was a recent buggy patch to the demangler that added calls to
>> malloc and realloc (2013-10-25 Gary Benson ).
>> That patch must be fixed or reverted before the 4.9 r
Hi,
Please review a small patch (backport from upstream) for libsanitizer.
We are having difficulties on our side and (likely) won't make a full
libsanitizer merge until early Jan.
Index: libsanitizer/ChangeLog
===
--- libsanitizer/C
On Wed, Dec 11, 2013 at 3:27 PM, Jakub Jelinek wrote:
> On Wed, Dec 11, 2013 at 03:21:32PM +0400, Konstantin Serebryany wrote:
>> What's wrong with C++? :)
>> Upstream we have 16 .c tests and 106 .cc tests in
>> compiler-rt/lib/tsan/lit_tests.
>> We typically
What's wrong with C++? :)
Upstream we have 16 .c tests and 106 .cc tests in
compiler-rt/lib/tsan/lit_tests.
We typically prefer .cc because imo C++ is a better language (even
when using what looks like the C subset).
But we need some .c tests to make sure that tsan still works w/o C++ run-time.
-
>
> Agreed. I guess our main question is whether such mechanism is really needed
> by developers.
We use the blacklist:
- with asan init-order-checker to disable checking some specific
globals by their type name ("bening" true positive)
- with msan to suppress true benign reports from zlib's defla
On Tue, Dec 10, 2013 at 12:10 PM, Jakub Jelinek wrote:
> On Tue, Dec 10, 2013 at 12:06:55PM +0400, Yury Gribov wrote:
>> > I'm strongly against the blacklist,
>> > that is not the way things are done in GCC,
>> > you have corresponding attribute to mark functions
>> > you don't want to instrument,
On Fri, Dec 6, 2013 at 5:10 PM, Yury Gribov wrote:
> Konstantin wrote:
>> Can you have a target specific config for the particular target
>> that will have its own shadow offset & scale?
>
> Yes, we have this but I don't see how this can help with code
> instrumentation overheads.
My comment about
On Fri, Dec 6, 2013 at 4:39 PM, Yury Gribov wrote:
> Konstantin wrote:
>
>> Jakub wrote:
>>> I'm strongly against the blacklist,
>> I don't like it either. We were forced to implement it by reality.
>> ...
>
>> imagine third-party code which you can build but can not change
>
> Same situation here
On Fri, Dec 6, 2013 at 4:09 PM, Jakub Jelinek wrote:
> On Fri, Dec 06, 2013 at 03:28:50PM +0400, Yury Gribov wrote:
>> Hi all,
>>
>> GCC version of Asan currently lacks options for detailed control
>> over code instrumentation. These are not usually necessary but for
>> embedded systems with scarc
es you get just 1/3 of instrumentation
and slowdown.
Of course, you also get a smaller amount of bugs.
>
> -Y
>
> ---
> From: Yury Gribov
> Sent: Friday, December 06, 2013 3:55PM
> To: Konstantin Serebryany
> Cc: GCC P
On Fri, Dec 6, 2013 at 3:28 PM, Yury Gribov wrote:
> Hi all,
>
> GCC version of Asan currently lacks options for detailed control over code
> instrumentation. These are not usually necessary but for embedded systems
> with scarce system resources Asan memory overhead of 2x-3x may often be
> unacce
M, H.J. Lu wrote:
> On Thu, Dec 5, 2013 at 4:59 AM, Konstantin Serebryany
> wrote:
>> On Thu, Dec 5, 2013 at 4:47 PM, H.J. Lu wrote:
>>>
>>> There are at least 2 fallouts:
>>>
>>> 1. -mx32 is broken.
>>
>> Please send a patch to the llv
On Thu, Dec 5, 2013 at 4:47 PM, H.J. Lu wrote:
> On Thu, Dec 5, 2013 at 3:18 AM, Konstantin Serebryany
> wrote:
>> On Thu, Dec 5, 2013 at 3:06 PM, Дмитрий Дьяченко wrote:
>>> clang' build is broken for me the same way
>>
>> Should be fixed now (only c
> The kernel and glibc check should be done at the toplevel.
> So what are the minimum kernel and glibc we want to
> support?
For us, the versions we want to support are those that have green
upstream buildbots and someone to keep them green.
It's hard or impossible to set a more precise combinati
On Thu, Dec 5, 2013 at 4:22 PM, Konstantin Serebryany
wrote:
> On Thu, Dec 5, 2013 at 1:05 AM, Jeff Law wrote:
>> On 12/03/13 22:08, Konstantin Serebryany wrote:
>>>
>>> We need
>>> a) patches that we can review and apply to the llvm repository (w/o
>&g
On Thu, Dec 5, 2013 at 1:05 AM, Jeff Law wrote:
> On 12/03/13 22:08, Konstantin Serebryany wrote:
>>
>> We need
>> a) patches that we can review and apply to the llvm repository (w/o
>> breaking the modern systems, of course)
>> b) a buildbot that would run 24/7
>> On Thu, Dec 05, 2013 at 02:06:52PM +0400, Konstantin Serebryany wrote:
>>> Another libsanitizer merge from upstream, r196489
>>> (Quick follow up after the r196090 merge)
>>
>> That commit breaks the build with:
>>
>> In file included from ../../.
Another libsanitizer merge from upstream, r196489
(Quick follow up after the r196090 merge)
Fixes (hopefully) .cfi and ppc32 support.
Tested on x86_64 Linux Ubuntu 12.04 box:
make -j 40 -C gcc check-g{cc,++}
RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} asan.exp'
The ubsan testing fails, but th
On Thu, Dec 5, 2013 at 12:18 PM, Jakub Jelinek wrote:
> On Thu, Dec 05, 2013 at 11:51:12AM +0400, Konstantin Serebryany wrote:
>> Committed upstream:
>> http://llvm.org/viewvc/llvm-project?view=revision&revision=196480
>
> LGTM, can we commit it after the merge you hav
my 2c: running all upstream tsan tests (ninja check-tsan) takes 10
seconds on my (beefy) machine and requires rather little memory.
Of course, you need lots of *virtual* memory.
On Thu, Dec 5, 2013 at 12:07 PM, Jakub Jelinek wrote:
> On Thu, Dec 05, 2013 at 10:12:36AM +0400, max wrote:
>> Hello,
1 - 100 of 284 matches
Mail list logo
