[llvm-dev] Compiling for AARCH64 (VMA=42)

[Adhemerval Zanella via llvm-dev]

On 25-11-2015 15:34, Simone Atzeni via llvm-dev wrote:
> Oh great thanks!
> 
> I actually have to do the same for PPC64 (44 and 46 bits).
> Right now I am doing it in the same way you do for AARCH, so I am defining a SANITIZER_PPC64_VMA variable.
> 
> The problem is that the check needs to be done at compile time in order to select for example the right memory mapping in san_platform.h.
> 
> Do you guys have already an idea how to automize that? 

It depends which sanitizer and the memory transformation constraints it
occurs.

For ASAN aarch64 currently uses the 39-bit VMA transformation for both
39 and 42-bit VMA. It has the downside of limiting total shadow memory
for less than 1/8 for higher VMA. For 42-bit VMA it limits to 64GB, 
where it would possible to define a higher shadow offset, increasing 
total shadow to 512GB.  

I am currently working on adding a transformation option to instead of 
using a shadow offset constant it reads an external variable provided
by compiler-rt. It is slower (average of 10% for specint2006, ranging 
from 5% to 30% hit compared to constant transformation), but provides 
a higher shadow memory pool for larger VMAs.

For DFSAN I plan to use a similar strategy [1] [2] by reading the
application mask externally from compiler-rt. Different from ASAN
(where a lower shadow mask value still works for higher value) 
current transformation relies on exact defined mask. I think it would
be possible to use a different formula to get the shadow address
to make it possible to use the same transformation for 39 and 42-bit
VMA for aarch64, but I do not think it would be feasible to make it
work for 48-bits as well (which is another VMA aarch64 supports that
is not currently supported).

For TSAN I am using a different strategy [3] which I think it might
be feasible to use for ppc64 as well (if it the case). Basically
it the same instrumentation for ASAN but done entirely on compiler-rt
code. It is also slower, but it shows a hit of about only 5% using
specint2006.

For MSAN I spent some time to use a map that would work for both
39 and 42 bits. And to increase total shadow usage for programs
mmap aarch64 mappings contains multiple application/shadow/origin
segments. I am not sure if this will work for 48-bit VMA and/or
if I would be able to use the same strategy to fragment the VMA
space to increase the memory availably to sanitizer.

Another option is to add a compiler flag to instruct the sanitizer
flag  which is the desirable VMA. It has the advantage the transformation
would be the fastest possible, however it has the disadvantage to
limit the binary to fail when run in an unexpected VMA. I do not
see this begin a default option and I have mixed felling if it
would be a good one to add.

[1] http://reviews.llvm.org/D14725
[2] http://reviews.llvm.org/D14724
[3] http://reviews.llvm.org/D14199

> 
> Best,
> Simone
> 
>> On Nov 25, 2015, at 10:29, Renato Golin <renato.golin at linaro.org> wrote:
>>
>> On 25 November 2015 at 17:19, Simone Atzeni via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>>> cmake -G "Ninja" -D SANITIZER_AARCH64_VMA=42 ..
>>
>> Hi Simone,
>>
>> That should actually be in CFLAGS:
>>
>> -DCMAKE_C_FLAGS='-DSANITIZER_AARCH64_VMA=42'
>> -DCMAKE_CXX_FLAGS='-DSANITIZER_AARCH64_VMA=42'
>>
>> It's a bit messy, sorry about that, but we're working on making the
>> VMA settings automatic without flags.
>>
>> cheers,
>> --renato
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>