On 25 March 2015 at 17:41, Konstantin Serebryany
<[email protected]> wrote:
> On Wed, Mar 25, 2015 at 4:33 AM, Renato Golin <[email protected]> wrote:
>> On 24 March 2015 at 15:46, Konstantin Serebryany
>> <[email protected]> wrote:
>>>> is there a way to initialize ASAN  mapping for Aarch64  during  runtime ?
>>>
>>> This *is* happening at run-time.
>>> Did you talk to others from Linaro who already reported to have
>>> working asan on aarch64?
>>> Renato?
>>
>> Hi Kostya,
>>
>> There are multiple issues here...
>>
>> Venkat was working on TSAN for AArch64 and got caught in a virtual
>> address problem. Not only AArch64 has less virtual address bits (39 or
>> 42, as opposed to 48 in x86_64),
>
> Is it only 39 and 42, or is there a 3-rd option?
>
I believe there is support for 48, but no HW available at present.

>
>> but they're different and there is no
>> generic solution. That's when he started working on ASAN to get the
>> 64-bit allocator working, and the virtual address space became an
>> issue once again. In the end, for the sanitizers to work well on all
>> AArch64 variations, we need to solve the virtual address issue.
>>
>> IIRC, ASAN has some macros to define the address ranges, so at least
>> part of the ranges logic is not runtime based, right?
>
> The values that define the location of the shadow are initialized at startup,
> so it should not be a problem.
>
> The values for Allocator64 have to be compile-time constants for
> better performance,
> but  Allocator64 is not going to work on 39 (and probably on 42) bits anyway.
> We'll need to use Allocator32.
>
Could you explain why it is not going to work? Should we think about fixing it?

>
>> I think the most
>> sane way to proceed is to:
>>
>> 1. Detect this at runtime and behave accordingly. This way we can use
>> the same binaries on all AArch64 machines.
>> 2. Detect this at configure time and hard-code the ranges. This way we
>> can not penalise the architectures where that is constant, ex. x86_64.
>> 3. Make into a cmake/configure option. This is especially important
>> for cross-compilation.
>>
>> Does that sound sensible?
>>
>> cheers,
>> --renato
>
> --
> You received this message because you are subscribed to the Google Groups 
> "address-sanitizer" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to