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? > 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. > 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.
