search for: r_aarch64_rel

Hi all, Working on lld aarch64 support I came across an issue where I am not sure which would be best design approach to solve. The aarch64 R_AARCH64_ABS64 relocation for PIC/PIE build requires a dynamic relocation (R_AARCH64_RELATIVE) with the value set as the addend of the relocation. For instance, when linking the crtbeginS.o which contains: Relocation section '.rela.init_array' at offset 0xd28 contains 1 entries: Offset Info Type Sym. Value Sym. Name + Addend 000000000000 00...

...# RUN: llvm-sometool --no-print-string | FileCheck %s --check-prefix=CHECK2 CHECK1<NAME>: mov [[REG:r[0-9]+]], #42 CHECK2-NOT: <NAME> It might work probably. We already have the ability to name parts of the output checked: // CHECK: Dynamic Relocations { // CHECK-NEXT: {{.*}} R_AARCH64_RELATIVE - [[BAR_ADDR:.*]] // CHECK: Symbols [ // CHECK-NEXT: Value: [[BAR_ADDR]] So adding a way for naming the whole line does not look an unreasonable/inconsistent extention to me I think. Best regards,​ George | Developer | Access Softek, Inc​​​​​​​ ________________________________ Fro...

...gt; > CHECK1<NAME>: mov [[REG:r[0-9]+]], #42 > > CHECK2-NOT: <NAME> > > > > It might work probably. We already have the ability to name parts of > > the output checked: > > > > // CHECK: Dynamic Relocations { > > // CHECK-NEXT: {{.*}} R_AARCH64_RELATIVE - [[BAR_ADDR:.*]] > > > > // CHECK: Symbols [ > > // CHECK-NEXT: Value: [[BAR_ADDR]] > > > > So adding a way for naming the whole line does not look > > an unreasonable/inconsistent extention to me I think. > > > > Best regards,​ > &g...

Hi all, There have been a few cases recently where I've noticed two test cases in the same lit test that do the same thing except invert the CHECK, to show that something is NOT present. I'm talking about something like the following: # RUN: llvm-sometool --print-string | FileCheck %s --check-prefix=STRING # RUN: llvm-sometool --no-print-string | FileCheck %s --check-prefix=NO-STRING #