Upstream change
http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/sanitizer_common/sanitizer_linux.cc?r1=168301&r2=168300&pathrev=168301
hopefully fixes the SPARC build.
We need to resolve http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55376
before we can automatically pull the fresh version
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, Konstantin Sereb
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
>>>
I am open to suggestions on how to a
From: Andrew Pinski
Date: Sat, 17 Nov 2012 19:34:34 -0800
> (glibc is the best at doing this).
It also uses "make" in pretty much the most inefficient way possible,
by causing it to consider 10s of thousands of prefix rules for every
rule target.
GLIBC has the same ifdef check that is being sug
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
>>
>>> I am open to suggestions on how to avoid forking the two versions.
>>> If we fork, the original asan
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.
>>> If we fork, the original asan team w
From: Diego Novillo
Date: Sat, 17 Nov 2012 22:26:24 -0500
> We have some new maintainers that are trying to understand how the
> system works.
Wouldn't we have someone become at least roughly familiar with these
kinds of things before we allow them to commit such an invasive set of
changes which
From: Konstantin Serebryany
Date: Sat, 17 Nov 2012 19:17:17 -0800
> I'd prefer to mention the ARCHs explicitly where possible, i.e.
> #if defined(__x86_64__) || definde (__sparc64__)
> instead of
>#if __WORDSIZE == 64 || ...
You really do need to check __x86_64__ as well the word size, in
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.
>> If we fork, the original asan team will not be able to cope with two
>> repositories.
>
> The main
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
>> repositories.
>
> The maint
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
> repositories.
The maintainer of the sanitizer's job is to do the merging and resolve
the
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
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
>>>return (void *)syscall(__NR_mmap2, addr, length, prot, fl
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
>>return (void *)syscall(__NR_mmap2, addr, length, prot, flags, fd, offset);
>
> The people making libsanitizer changes ar
From: Eric Botcazou
Date: Sun, 18 Nov 2012 00:18:15 +0100
> error: '__NR_mmap2' was not declared in this scope
>return (void *)syscall(__NR_mmap2, addr, length, prot, flags, fd, offset);
The people making libsanitizer changes are really going to have to
stop making i386 specific changes to t
> So, here is the (IMO obvious) patch to enable libsanitizer's build on
> sparc linux, even if asan is not supported on that platform yet.
>
> OK for trunk?
>
> libsanitizer/ChangeLog:
>
> * configure.tgt: Enable sparc linux.
libtool: compile: /home/ebotcazou/build/./gcc/g++ -
B/home/ebo
David Miller writes:
> From: Dodji Seketeli
> Date: Thu, 15 Nov 2012 11:56:40 +0100
>
>> David Miller wrote
>>
>>> From: Dodji Seketeli
>>> Date: Wed, 14 Nov 2012 14:26:40 +0100
>>>
>>> > I guess we could do that. That would build libsanitizer, but asan will
>>> > still not be available on
From: Dodji Seketeli
Date: Thu, 15 Nov 2012 11:56:40 +0100
> David Miller wrote
>
>> From: Dodji Seketeli
>> Date: Wed, 14 Nov 2012 14:26:40 +0100
>>
>> > I guess we could do that. That would build libsanitizer, but asan will
>> > still not be available on sparc if the asan_shadow_offset() t
On Thu, Nov 15, 2012 at 5:56 AM, Dodji Seketeli wrote:
> David Miller wrote
>
>> From: Dodji Seketeli
>> Date: Wed, 14 Nov 2012 14:26:40 +0100
>>
>> > I guess we could do that. That would build libsanitizer, but asan will
>> > still not be available on sparc if the asan_shadow_offset() target h
David Miller wrote
> From: Dodji Seketeli
> Date: Wed, 14 Nov 2012 14:26:40 +0100
>
> > I guess we could do that. That would build libsanitizer, but asan will
> > still not be available on sparc if the asan_shadow_offset() target hook
> > is not provided. Is that OK to you?
>
> Yes.
So, her
20 matches
Mail list logo
