similar to: Dynamic VMA in Sanitizers for AArch64

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,

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

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

Hi, I am trying to compile LLVM for AARCH (VMA=42), here my cmake command: cmake -G "Ninja" -D SANITIZER_AARCH64_VMA=42 .. But I get the following warning: ------------------------------------------------------------------------------------------ CMake Warning: Manually-specified variables were not used by the project: SANITIZER_AARCH64_VMA

Hello, I have been working on porting ASan to AArch64. I am building compiler-rt in "standalone mode" targeting aarch64. My build is successful, but I get the following runtime error when I run an ASan enabled executable through qemu-aarch64: ==29184==Parsed ASAN_OPTIONS: verbosity=1 ==29184==AddressSanitizer: failed to intercept '__isoc99_printf' ==29184==AddressSanitizer:

Hi Adhemerval, Some UBSan tests are timing out randomly. http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full ex: http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/902 http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/894 http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/906

On 2 November 2015 at 18:40, Adhemerval Zanella <adhemerval.zanella at linaro.org> wrote: > Is it 39 or 42-bit VMA? I noted a 42-bit issue in segment definition > that I have fixed on my TSAN unification mapping patch [1]: No, that's 39-bit. cheers, --renato

I'd like to mention that test does not allocate 30TB, it allocates 1TB, the rest, ~20TB, is reserved (but not actually used) for ASan shadow memory, it should not be a problem by itself. The test on your bot failed because it tried to reserve 27TB of memory, which is more than set by ulimit earlier in this test. I do not immediately see why it wants to reserve that much shadow for AArch64

Hi, I experienced a crash in code compiled with Clang 10.0.0 due to a misaligned 64-bit data access. The (ARMv8) CPU is configured with SCTL.A == 1 (alignment check enable). With SCTLR.A == 0 the code runs as expected. After some investigation I came up with the following reproducer: ---8<-------8<-------8<-------8<-------8<-------8<-------8<------- $ cat test.c extern char

Hi all, opt and opt + llc generate the difference aarch64 asm code for the following LLVM code. Is it intended behavior? I expected (A) because I cast %p from i192* to i64*. The information is dropped by opt and 8-byte padding is inserted or I write a bad code? % cat a.ll define void @store0_to_p4(i192* %p) { %p1 = bitcast i192* %p to i64* %p2 = getelementptr i64, i64* %p1, i64 3 %p3 =

As usual, written and (build-)tested on 2.6.27.4 and made apply to the 2.6.18 tree without further testing. Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: head-2008-11-04/drivers/xen/blktap/blktap.c =================================================================== --- head-2008-11-04.orig/drivers/xen/blktap/blktap.c 2008-10-01 16:35:04.000000000 +0200 +++

The vma field of struct nouveau_framebuffer is a special field for the the accelerated fbdev console. Hence there's at most one single instance for the active console. Moving it into struct nouveau_fbdev makes struct nouveau_framebuffer slightly smaller and brings it closer to struct drm_framebuffer. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> ---

Since hmm_range_fault() doesn't use the struct hmm_range vma field, remove it. Suggested-by: Jason Gunthorpe <jgg at mellanox.com> Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> Cc: "Jérôme Glisse" <jglisse at redhat.com> Cc: Christoph Hellwig <hch at lst.de> --- drivers/gpu/drm/nouveau/nouveau_svm.c | 7 +++---- include/linux/hmm.h

find_vma_intersection(mm, start, end) only guarantees that end is greater than or equal to vma->vm_start but doesn't guarantee that start is greater than or equal to vma->vm_start. The calculation for the intersecting range in nouveau_svmm_bind() isn't accounting for this and can call migrate_vma_setup() with a starting address less than vma->vm_start. This results in

From: Ralph Campbell <rcampbell at nvidia.com> [ Upstream commit b92103b559c77abc5f8b7bec269230a219c880b7 ] find_vma_intersection(mm, start, end) only guarantees that end is greater than or equal to vma->vm_start but doesn't guarantee that start is greater than or equal to vma->vm_start. The calculation for the intersecting range in nouveau_svmm_bind() isn't accounting for

From: Ralph Campbell <rcampbell at nvidia.com> [ Upstream commit b92103b559c77abc5f8b7bec269230a219c880b7 ] find_vma_intersection(mm, start, end) only guarantees that end is greater than or equal to vma->vm_start but doesn't guarantee that start is greater than or equal to vma->vm_start. The calculation for the intersecting range in nouveau_svmm_bind() isn't accounting for

From: Ralph Campbell <rcampbell at nvidia.com> [ Upstream commit b92103b559c77abc5f8b7bec269230a219c880b7 ] find_vma_intersection(mm, start, end) only guarantees that end is greater than or equal to vma->vm_start but doesn't guarantee that start is greater than or equal to vma->vm_start. The calculation for the intersecting range in nouveau_svmm_bind() isn't accounting for

Hi Renato, > > I'm trying to add pseudo 64-bit load and store instructions for AArch64, which > > should have latencies set to "1" while being otherwise exactly the same as > > normal load and store instructions. > > Can I ask why would you need that? This is the only way I found to stop Machine Instruction Scheduler from reordering load and store

Sorry, quick message to ignore what I wrote before, I got myself confused (probably you too), With a recent trunk build I get this: f: adrp x8, g ldr x8, [x8, :lo12:g] mov w2, #16 mov x1, x0 mov x0, x8 b memcmp This looks more correct, and I need to look a bit more into this (and how clang 10.0.0 behaves).

Hello LLVM, I'm playing with a new ISD::OPAQUE instruction to make hoisting first class and eliminate a lot of tweaky flag setting/checking around opaque constants. It's going well for the IR and x86, but I now I need to sort out details for all the other targets. To start, can someone please advise on the AAarch64 equivalent of these X86 patterns? // Opaque values become mov immediate