On Mon, Dec 3, 2012 at 10:02 PM, David Miller <[email protected]> wrote:
> From: Konstantin Serebryany <[email protected]>
> Date: Tue, 27 Nov 2012 18:12:00 +0400
>
>> On Wed, Nov 21, 2012 at 9:05 PM, Konstantin Serebryany
>> <[email protected]> wrote:
>>> On Wed, Nov 21, 2012 at 8:40 PM, David Miller <[email protected]> wrote:
>>>> From: Konstantin Serebryany <[email protected]>
>>>> 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 it's not *that* difficult.
>>> Looking at it carefully, the major problem I can see is that some
>>> other constants are defined based on this one.
>>> Give me a few days to resolve it...
>>> http://code.google.com/p/address-sanitizer/issues/detail?id=128
>>
>> http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193849 removes the
>> kPageSize constant in favor of a function call.
>> Please give it a try.
>>
>> BTW, libsanitizer now has a usable process to quickly pull the upstream
>> changes.
>> It should make it easier for us to iterate on platform-specific patches.
>
> So, with the hacks for unaligned accesses, Sparc seems to be working
> here.
>
> The only changes to libsantizier is to put __sparc__ checks where
> __powerpc__ checks exist in the unwind code.
Like this?
===================================================================
--- asan/asan_linux.cc (revision 169136)
+++ asan/asan_linux.cc (working copy)
@@ -158,7 +158,9 @@
stack->trace[0] = pc;
if ((max_s) > 1) {
stack->max_size = max_s;
-#if defined(__arm__) || defined(__powerpc__) || defined(__powerpc64__)
+#if defined(__arm__) || \
+ defined(__powerpc__) || defined(__powerpc64__) || \
+ defined(__sparc__)
_Unwind_Backtrace(Unwind_Trace, stack);
// Pop off the two ASAN functions from the backtrace.
stack->PopStackFrames(2);
>
> Are there any clear thoughts about what we should do in the end
> wrt. the stack ASAN alignment issues? Do we plan to 32-byte
> align the stack variables or similar? Otherwise we need to add
> some ugly code to do half-word/byte at a time accesses, as needed.
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 ~2x faster.
8-byte aligned redzones trade some CPU for some stack memory and
probably slightly increase
the chances of catching large (33+ bytes off) buffer overflows.
For strict alignment architectures 8-byte aligned redzones is
obviously not a choice.
We either need to align the redzones by 32 always, or for some platforms.
Either is fine for me.
--kcc
