I've committed a flag to the LLVM implementation to not realign the
stack (-mllvm -asan-realign-stack=0).
On Xeon W3690 I've measured no performance difference (tried C/C++
part of SPEC2006).
So, on x86 it's probably the right thing to not realign the stack.
--kcc
On Mon, Dec 3, 2012 at 10:41 PM,
On 2012-11-21 11:28, Peter Bergner wrote:
> + if (Unwind_GetBP(ctx) == p->bp) {
I've mentioned multiple times that BP is unusable on most RISC.
You need to be looking at SP.
r~
From: Konstantin Serebryany
Date: Mon, 3 Dec 2012 22:44:15 +0400
> 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
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().
>>> The Sparc PC is actually 8 bytes
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 aligned),
> although I suspect 32-byte aligned redzones should be ~2
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().
>> The Sparc PC is actually 8 bytes after the caller's jump. Sparc has
>> a delay slot, the place
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
>> vs 8-byte aligned)
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
>>> __powerpc__ checks exist in the unwind cod
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 aligned),
> although I suspect 32-byte aligned redzones should be ~2
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
>> __powerpc__ checks exist in the unwind code.
>
> Like this?
>
> ==
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:
From: Konstantin Serebryany
Date:
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:
>>> From: Konstantin Serebryany
>>> Date: Wed, 21 Nov 2012 19:39:52 +0400
>>>
There are various other
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'm trying to understand wh
>> While trying to add support for ARM (AArch32 GNU / Linux) implementation for
>> GCC after-hours but still keep seeing failures on my chromebook running an
>> ubuntu fs on a ChrOS kernel, because the shadow memory apparently overlaps
>> with normal memory. Has anyone else hit this while porting ?
From: Peter Bergner
Date: Wed, 21 Nov 2012 17:46:57 -0600
> If you have a suggested change/patch that does that, let me know
> and I can try it out on powerpc to make sure it works for us too.
I will try to do so, but I am pretty sure at this point that
it will end up being some time early next
On Wed, 2012-11-21 at 15:27 -0500, David Miller wrote:
> Actually I looked more closely at this, and the trigger is hit one
> stack frame too late on sparc.
>
> The BP computed in the memcmp() interceptor is the frame pointer
> %fp, but on sparc that's the CFA of the caller, main() in the
> case o
From: Jakub Jelinek
Date: Wed, 21 Nov 2012 21:30:37 +0100
> On Wed, Nov 21, 2012 at 03:27:16PM -0500, David Miller wrote:
>> Actually I looked more closely at this, and the trigger is hit one
>> stack frame too late on sparc.
>
> Are you testing with -fno-builtin-memcmp? Without it the check is
On Wed, Nov 21, 2012 at 03:27:16PM -0500, David Miller wrote:
> Actually I looked more closely at this, and the trigger is hit one
> stack frame too late on sparc.
Are you testing with -fno-builtin-memcmp? Without it the check is done
directly in main...
Jakub
From: David Miller
Date: Wed, 21 Nov 2012 12:54:17 -0500 (EST)
> From: Peter Bergner
> Date: Wed, 21 Nov 2012 11:28:51 -0600
>
>> On Tue, 2012-11-20 at 23:19 -0500, David Miller wrote:
>>> The address violation detection seems to work properly and the only
>>> thing that seems to be left are so
While trying to add support for ARM (AArch32 GNU / Linux) implementation for
GCC after-hours but still keep seeing failures on my chromebook running an
ubuntu fs on a ChrOS kernel, because the shadow memory apparently overlaps
with normal memory. Has anyone else hit this while porting ?
I've he
From: Peter Bergner
Date: Wed, 21 Nov 2012 11:28:51 -0600
> On Tue, 2012-11-20 at 23:19 -0500, David Miller wrote:
>> The address violation detection seems to work properly and the only
>> thing that seems to be left are some backtrace/unwind issues. These
>> are perhaps similar to the unwind bi
On Tue, 2012-11-20 at 23:19 -0500, David Miller wrote:
> The address violation detection seems to work properly and the only
> thing that seems to be left are some backtrace/unwind issues. These
> are perhaps similar to the unwind bits that the powerpc folks ran
> into.
David, does the following
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, 2012-11-21 at 19:39 +0400, Konstantin
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, 2012-11-21 at 19:39 +0400, Konstantin Serebryany wrote:
On Wed, Nov 21, 2012 at 7:29 PM, David Miller wrote:
From: Konstantin
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
> is such a difficult endeavour.
Maybe
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
is such a difficult endeavour.
Andrew Pinski writes:
> Just to follow up, MIPS64 have the following (selectable at kernel
> compile time) page sizes:
> 4k, 8k, 16k, 32k and 64k. So is another target where the page size is
> not constant just like PPC.
As does ia64 (common page sizes are 16k and 64k).
Andreas.
--
Andreas S
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, 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
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
>> >
>> >> Today, kPageSize is used in sever
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
> >
> >> Today, kPageSize is used in several places where it is expected to be
> >> a compile-time const
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 with GetPageSize() is safe, it
>>
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 with GetPageSize() is safe, it
> would need very significant testing (including performance tes
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 the SPARC
>>> build. We will not be ac
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 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.
>
> FWIW, here are the changes I am using which, besides th
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.
FWIW, here are the changes I am using which, besides the sparc backend
bits, has some temporary workarounds for the issues I brough
36 matches
Mail list logo
