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,
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 Fri, Feb 22, 2013 at 8:32 PM, Jakub Jelinek wrote:
> On Fri, Feb 15, 2013 at 12:47:30PM +0400, Konstantin Serebryany wrote:
>> Sure. ASAN_FIXED_MAPPING should be used for performance measurements
>> only -- this is not a release option.
>> (Added a more precise comment).
&
+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 testsuite).
>
> I have chosen to bundle -funwind-table with -fsanitize=* so that a
On Thu, Mar 28, 2013 at 12:07 PM, Jakub Jelinek wrote:
> On Thu, Mar 28, 2013 at 12:00:23PM +0400, Evgeniy Stepanov wrote:
>> We do it because newer versions of Android use PIE binaries, and,
>> combined with other specifics of address space on Linux/ARM, there is
>> no space for ASan shadow anywh
[resending in plain text]
On Fri, Apr 5, 2013 at 10:24 AM, Konstantin Serebryany
wrote:
> Hi Bernhard,
>
> The libsanitizer code is the exact copy of some revision of the upstream
> code in LLVM repo.
> libsanitizer/README.gcc:
> Trivial and urgent fixes (portability, build f
On Fri, Apr 5, 2013 at 10:37 AM, Jakub Jelinek wrote:
> On Thu, Apr 04, 2013 at 09:53:30PM +0200, Bernhard Reutner-Fischer wrote:
>> uClibc can be built without Largefile support, add the corresponding
>> guards. uClibc does not have __libc_malloc()/__libc_free(), add guard.
>
> Ugh, this is very
On Fri, Apr 19, 2013 at 7:59 AM, Christophe Lyon
wrote:
> On 18 April 2013 11:30, Christophe Lyon wrote:
>> On 4 April 2013 14:19, Christophe Lyon wrote:
>>> ~/src/qemu/qemu-git/arm-linux-user/qemu-arm -cpu cortex-a9 -R 0 -L
>>> /home/lyon/src/GCC/builds/gcc-fsf-asan-arm-none-linux-gnueabihf/sys
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
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
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 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
>> 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
[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:
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
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
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 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
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 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
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 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
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 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
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
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 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.
>
&
>
>> > 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]
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
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
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: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
>> 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 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
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 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: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: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
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 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
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
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 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
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 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
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
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
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
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
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 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
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 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
>
> 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 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
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, 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
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
>> >
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, Dec 13, 2012 at 1:30 AM, Jakub Jelinek wrote:
> On Wed, Dec 12, 2012 at 10:16:49PM +0100, Dodji Seketeli wrote:
>> Independently of this review, I think it's be interesting to hear
>> Kostya's voice on:
>>
>> Jakub Jelinek writes:
>>
>> > 2) In large-func-test-1.C, I had to stop matching
2012 at 12:36 PM, Jakub Jelinek wrote:
> On Thu, Dec 13, 2012 at 11:44:12AM +0400, Konstantin Serebryany wrote:
>> We are discussing it from time to time.
>> Sometimes, if e.g. an error happens inside a qsort callback,
>> the fp-based unwinder fails to unwind through libc, w
On Thu, Jan 10, 2013 at 2:59 PM, Jakub Jelinek wrote:
> On Thu, Jan 10, 2013 at 11:07:26AM +0400, Konstantin Serebryany wrote:
>> >> Our internal LLVM bots (Linux, Mac and Android) are also green, but
>> >> since the changes are large something may potentially bre
On Thu, Jan 10, 2013 at 4:23 PM, Jakub Jelinek wrote:
> On Thu, Jan 10, 2013 at 03:57:44PM +0400, Konstantin Serebryany wrote:
>> > That is not sufficient. You can have PR_SET_NAME defined in the headers,
>> > but still the underlying kernel doesn't need to handle it.
ok, thanks!
(that was quick!)
--kcc
On Fri, Jan 18, 2013 at 9:39 PM, Jack Howarth wrote:
>Upstream llvm compiler-rts asan subdirectory now includes files with the
> *.inc suffix.
> The attached patch adds this new suffix to the list of merged files. Okay for
> gcc trunk?
> Jack
>
On Wed, Jan 23, 2013 at 3:13 PM, Jakub Jelinek wrote:
> On Wed, Jan 23, 2013 at 02:31:57PM +0400, Konstantin Serebryany wrote:
>> The attached patch is the libsanitizer merge from upstream r173241.
>>
>> Lots of changes. Among other things:
>> - slow CFI-based un
On Wed, Feb 13, 2013 at 3:59 PM, Jakub Jelinek wrote:
> On Wed, Feb 13, 2013 at 11:32:00AM +0100, Jakub Jelinek wrote:
>> On Wed, Feb 13, 2013 at 02:28:25PM +0400, Konstantin Serebryany wrote:
>> > Right. In LLVM we test only with ASAN_FLEXIBLE_MAPPING_AND_OFFSET==1,
>>
On Wed, Feb 13, 2013 at 4:48 PM, Jakub Jelinek wrote:
> On Wed, Feb 13, 2013 at 04:32:33PM +0400, Konstantin Serebryany wrote:
>> > Unfortunately, it seems everything fails with that change :( on Linux.
>> > The problem is that the default prelink library range for x86_64 i
On Wed, Feb 13, 2013 at 5:07 PM, Jakub Jelinek wrote:
> On Wed, Feb 13, 2013 at 04:57:30PM +0400, Konstantin Serebryany wrote:
>> On Wed, Feb 13, 2013 at 4:48 PM, Jakub Jelinek wrote:
>> > On Wed, Feb 13, 2013 at 04:32:33PM +0400, Konstantin Serebryany wrote:
>> >
On Wed, Feb 13, 2013 at 10:29 PM, H.J. Lu wrote:
> On Wed, Feb 13, 2013 at 1:19 AM, Konstantin Serebryany
> wrote:
>> Hi,
>>
>> The attached patch is the libsanitizer merge from upstream r175042.
>>
>> Lots of changes. Among other things:
>> -
Thanks!
This'll let us think about fixing 7fff8000+prelink w/o a rush.
Still, can we switch to using asan-rt in
ASAN_FLEXIBLE_MAPPING_AND_OFFSET=1 mode?
This way we will have fewer differences between gcc variant and upstream
and will be able to change the offset w/o changing the rt at all.
(and t
On Thu, Feb 14, 2013 at 12:41 PM, Jakub Jelinek wrote:
> On Thu, Feb 14, 2013 at 12:17:27PM +0400, Konstantin Serebryany wrote:
>> On Wed, Feb 13, 2013 at 8:03 PM, Jakub Jelinek wrote:
>> > Hi!
>> >
>> > This patch backports the asan_test.cc changes
The patch seems to work on a simple test. Let me digest it.
I am trying to understand if there are problems with it other than the
added complexity (which is what I don't like the most).
-Wl,-Ttext-segment=0x36 does not work with binutils-gold.
gold understands -Wl,-Ttext=0x36, but
On Thu, Feb 14, 2013 at 4:19 PM, Jakub Jelinek wrote:
> On Thu, Feb 14, 2013 at 03:55:47PM +0400, Konstantin Serebryany wrote:
>> The patch seems to work on a simple test. Let me digest it.
>> I am trying to understand if there are problems with it other than the
>> added
On Thu, Feb 14, 2013 at 4:19 PM, Jakub Jelinek wrote:
> On Thu, Feb 14, 2013 at 03:55:47PM +0400, Konstantin Serebryany wrote:
>> The patch seems to work on a simple test. Let me digest it.
>> I am trying to understand if there are problems with it other than the
>> added
Ian, there is a question for you below.
On Fri, Feb 15, 2013 at 12:26 PM, Jakub Jelinek wrote:
> On Fri, Feb 15, 2013 at 11:45:15AM +0400, Konstantin Serebryany wrote:
>> On Thu, Feb 14, 2013 at 4:19 PM, Jakub Jelinek wrote:
>> > On Thu, Feb 14, 2013 at 03:55:47PM +0400, Kon
On Fri, Feb 15, 2013 at 1:05 PM, Jakub Jelinek wrote:
> On Fri, Feb 15, 2013 at 12:47:30PM +0400, Konstantin Serebryany wrote:
>> This is ungood.
>> First, clang doesn't like it at all:
>> prelink1.cc:18:18: error: init_priority attribute requires integer
>>
On Fri, Feb 15, 2013 at 1:37 PM, Jakub Jelinek wrote:
> On Fri, Feb 15, 2013 at 01:30:18PM +0400, Konstantin Serebryany wrote:
>> > OT, unrelated thing, in include/asan_interface.h there is one
>> > #if __has_feature(address_sanitizer)
>> > which for GCC shoul
I've submitted http://llvm.org/viewvc/llvm-project?view=revision&revision=175263
If it survives a few days of testing I'll do another merge to gcc.
--kcc
On Fri, Feb 15, 2013 at 1:47 PM, Konstantin Serebryany
wrote:
> On Fri, Feb 15, 2013 at 1:37 PM, Jakub Jelinek wrote:
On Mon, Feb 18, 2013 at 12:20 PM, Jakub Jelinek wrote:
> On Fri, Feb 15, 2013 at 07:39:28AM -0800, Ian Lance Taylor wrote:
>> On Thu, Feb 14, 2013 at 11:45 PM, Konstantin Serebryany
>> wrote:
>> >
>> > Unfortunately, the test does not work if gold is the system l
On Thu, Feb 21, 2013 at 5:21 PM, Jakub Jelinek wrote:
> On Thu, Feb 21, 2013 at 05:15:51PM +0400, Konstantin Serebryany wrote:
>> This commit breaks the build if the BFD linker is used (I have gold on
>> my box, so I missed it).
>>
>> Short repro:
>
Thanks!
Does this need to regenerate libsanitizer/asan/Makefile.in ?
(It'll take a while for me to do this on Mac)
--kcc
On Thu, Feb 21, 2013 at 8:04 PM, Jack Howarth wrote:
> The attached patch fixes the broken bootstrap on darwin in libsanitizer due
> to the
> deprecation of the dynamic/as
build the static libasan with -fPIC, it doesn't hurt.
Anyway, I've just committed
http://llvm.org/viewvc/llvm-project?rev=175871&view=rev with
asan_preinit.cc
--kcc
On Thu, Feb 21, 2013 at 5:26 PM, Konstantin Serebryany
wrote:
> On Thu, Feb 21, 2013 at 5:21 PM, Jakub Jelinek
On Fri, Feb 22, 2013 at 4:58 PM, Jakub Jelinek wrote:
> On Fri, Feb 22, 2013 at 11:53:39AM +0400, Konstantin Serebryany wrote:
>> Jakub, thanks again for cleaning up my mess.
>>
>> Here is a question regarding your fix:
>> > -#if ASAN_USE_PREINIT_ARRAY
>> >
201 - 284 of 284 matches
Mail list logo
