search for: shadow_offset

...int __asan_get_free_stack(void *addr, void **trace, size_t *frame_count, void **top_frame_bp, int *thread_id); // Useful for calling from the debugger to get the current shadow memory // mapping. void __asan_get_shadow_mapping(size_t *shadow_scale, size_t *shadow_offset); Hi, I would like to improve the debugging experience for ASan. The idea is to have a couple of useful commands in LLDB (probably implemented as Python scripts) that could help the user when they are debugging an ASan-enabled binary. We already have some debugging API (asan_interface.h): //...

...| `[0x001000000000, 0x0011ffffffff]` || LowShadow || || `[0x000000000000, 0x000fffffffff]` || LowMem || MemToShadow(shadow): 0x001200000000 0x00123fffffff 0x001280000000 0x0013ffffffff redzone=16 max_redzone=2048 quarantine_size=256M malloc_context_size=30 SHADOW_SCALE: 3 SHADOW_GRANULARITY: 8 SHADOW_OFFSET: 1000000000 ==29184==ERROR: AddressSanitizer failed to allocate 0xc00000000 (51539607552) bytes at address 1400000000 (errno: 12) ==29184==ReserveShadowMemoryRange failed while trying to map 0xc00000000 bytes. Perhaps you're using ulimit -v This appears to be the same issue discussed in this t...

...rceptors initialized || `[0x20000000, 0xffffffff]` || HighMem || || `[0x04000000, 0x1fffffff]` || HighShadow || || `[0x00040000, 0x03ffffff]` || ShadowGap || MemToShadow(shadow): 0x00000000 0x00000000 0x00800000 0x03ffffff red_zone=16 malloc_context_size=30 SHADOW_SCALE: 3 SHADOW_GRANULARITY: 8 SHADOW_OFFSET: 0 ==28210==Shadow memory range interleaves with an existing memory mapping. ASan cannot proceed correctly. ABORTING. ==28210==Process memory map follows: 0x00008000-0x0000f000 /data/data/djpeg 0x0000f000-0x00010000 /data/data/djpeg 0x00010000-0x00011000 0x40094000-0x400a700...

...|| LowShadow || || `[0x000000000000, 0x00007fff7fff]` || LowMem || MemToShadow(shadow): 0x00008fff7000 0x000091ff6dff 0x004091ff6e00 0x02008fff6fff redzone=16 max_redzone=2048 quarantine_size_mb=256M thread_local_quarantine_size_kb=1024K malloc_context_size=30 SHADOW_SCALE: 3 SHADOW_GRANULARITY: 8 SHADOW_OFFSET: 0x7fff8000 ==3401806==Installed the sigaction for signal 11 ==3401806==Installed the sigaction for signal 7 ==3401806==Installed the sigaction for signal 8 ==3401806==T0: stack [0x7fff3bf5c000,0x7fff3c75c000) size 0x800000; local=0x7fff3c759244 ==3401806==AddressSanitizer Init done ➜ readelf -d h...

...oShadow(shadow): 0x00008fff7000 0x000091ff6dff 0x004091ff6e00 0x02008fff6fff >> redzone=16 >> max_redzone=2048 >> quarantine_size_mb=256M >> thread_local_quarantine_size_kb=1024K >> malloc_context_size=30 >> SHADOW_SCALE: 3 >> SHADOW_GRANULARITY: 8 >> SHADOW_OFFSET: 0x7fff8000 >> ==3401806==Installed the sigaction for signal 11 >> ==3401806==Installed the sigaction for signal 7 >> ==3401806==Installed the sigaction for signal 8 >> ==3401806==T0: stack [0x7fff3bf5c000,0x7fff3c75c000) size 0x800000; >> local=0x7fff3c759244 >>...

...ffffffff]` || HighMem || > || `[0x04000000, 0x1fffffff]` || HighShadow || > || `[0x00040000, 0x03ffffff]` || ShadowGap || > MemToShadow(shadow): 0x00000000 0x00000000 0x00800000 0x03ffffff > red_zone=16 > malloc_context_size=30 > SHADOW_SCALE: 3 > SHADOW_GRANULARITY: 8 > SHADOW_OFFSET: 0 > ==28210==Shadow memory range interleaves with an existing memory > mapping. ASan cannot proceed correctly. ABORTING. > ==28210==Process memory map follows: > 0x00008000-0x0000f000 /data/data/djpeg > 0x0000f000-0x00010000 /data/data/djpeg > 0x00010000-0x0001...

On 25 September 2015 at 20:11, Jakub Jelinek <jakub at redhat.com> wrote: > Note, in our distros we are shipping 42-bit VMA and are using patch on > top of vanilla libsanitizer (with the 1UL << 36 shadow offset) and I don't > remember any bugs reported against this not working (and the testsuite works > too). So, assuming 39-bit VMA works too, that would show that at

Hi folks, 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

Hello, LLVM developers I would like to ask about the changes in the "nonpublic" AddressSanitizer flags in llvm 3.5. Prior to 3.5 (namely, on 3.4.2) there was a compile-time flag to control the shadow offset. For example, one could do the following to force the large offset: -mllvm -asan-mapping-offset-log=44 Now, it has been removed and on x86_64 linux the smaller offset is always