On Wed, Mar 25, 2015 at 1:27 PM, Christophe Lyon <[email protected]> wrote: > 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.
Any publicly known roadmap here? If 48 will appear soon, I don't want to hear about tsan on 39 and 42 -- this is not a trivial task to solve and tsan will function well only if there is plenty of VA *and* physical memory. Or we are stuck with 39 and 42 for a long time? This is not related to asan. We can make asan work on 16 bit AS, if we need to. > >> >>> 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? "fixing it" means using Allocator32. Allocator64 is designed in assumption that there is a huge chunk of AS available to the allocator to place it's 50+ size classes in fixed (constant) address ranges. Every region dedicated to a given size class should be at least the size of the physical memory available on the system. Suppose we have may have up to 32Gb available on an AArch device. (even if not today, in near future we will have that much, right?) It means we need 64x32Gb of address space, which is 2^41 -- we can not fit this into 42-bit AS. If we try hard and limit ourselves with smaller amount of physical RAM in a device, we may be able to squeeze Allocator64 into 42 AS, but not into 39 AS. > >> >>> 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. -- 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.
