[llvm-dev] Dynamic VMA in Sanitizers for AArch64

[Evgenii Stepanov via llvm-dev]

Jakub makes a good point, are you sure that there is no single shadow
offset value that works for all VMA variants? What exactly breaks when
1<<36 is used on 42-bit VMA?


On Fri, Sep 25, 2015 at 3:28 AM, Yury Gribov via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> On 09/25/2015 01:27 PM, Yury Gribov wrote:
>>
>> On 09/25/2015 11:53 AM, Jakub Jelinek via llvm-dev wrote:
>>>
>>> On Fri, Sep 25, 2015 at 01:19:48AM -0700, Renato Golin wrote:
>>>>
>>>> After long talks with lots of people, I think we have a winning
>>>> strategy to deal with the variable nature of VMA address in AArch64.
>>>> It seems that the best way forward is to try the dynamic calculation
>>>> at runtime, evaluate the performance, and then, only if the hit is too
>>>> great, think about compile-time alternatives. I'd like to know if
>>>> everyone is in agreement, so we could get cracking.
>>>
>>>
>>> You mean you want a dynamic shadow offset on aarch64 as opposed to
>>> fixed kAArch64_ShadowOffset64 (1UL << 36) one?
>>> I think this is completely unnecessary, all you need to change is
>>> libsanitizer internals IMNSHO, all that is needed is to make runtime
>>> decisions during libasan initialization on the memory layout, and
>>> also (because 39 bit VMA is too slow), dynamic decision whether to use
>>> 32-bit or 64-bit allocator.  See
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435
>>> for details.
>>
>>
>> Added kcc.
>>
>> FYI optional dynamic offset would also help in not-so-rare situations
>> when ASan's shadow range is stolen by early constructors in unsanitized
>> libraries.
>
>
> And - we'll finally be able to run ASan under Valgrind)
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev