maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/MC/AArch64/error-location.s

52 lines
1.5 KiB
ArmAsm
Raw Normal View History

[ARM,AArch64] Store source location for values in assembly files The MCValue class can store a SMLoc to allow better error messages to be emitted if an error is detected after parsing. The ARM and AArch64 assembly parsers were not setting this, so error messages did not have source information. Differential Revision: http://reviews.llvm.org/D14645 llvm-svn: 253219
2015-11-17 00:22:47 +08:00
// RUN: not llvm-mc -triple aarch64--none-eabi -filetype obj < %s -o /dev/null 2>&1 | FileCheck %s
[Assembler] Make fatal assembler errors non-fatal Currently, if the assembler encounters an error after parsing (such as an out-of-range fixup), it reports this as a fatal error, and so stops after the first error. However, for most of these there is an obvious way to recover after emitting the error, such as emitting the fixup with a value of zero. This means that we can report on all of the errors in a file, not just the first one. MCContext::reportError records the fact that an error was encountered, so we won't actually emit an object file with the incorrect contents. Differential Revision: http://reviews.llvm.org/D14717 llvm-svn: 253328
2015-11-17 18:00:43 +08:00
// Note: These errors are not always emitted in the order in which the relevant
// source appears, this file is carefully ordered so that that is the case.
[ARM,AArch64] Store source location for values in assembly files The MCValue class can store a SMLoc to allow better error messages to be emitted if an error is detected after parsing. The ARM and AArch64 assembly parsers were not setting this, so error messages did not have source information. Differential Revision: http://reviews.llvm.org/D14645 llvm-svn: 253219
2015-11-17 00:22:47 +08:00
.text
// CHECK: :[[@LINE+1]]:{{[0-9]+}}: error: symbol 'undef' can not be undefined in a subtraction expression
.word (0-undef)
[Assembler] Make fatal assembler errors non-fatal Currently, if the assembler encounters an error after parsing (such as an out-of-range fixup), it reports this as a fatal error, and so stops after the first error. However, for most of these there is an obvious way to recover after emitting the error, such as emitting the fixup with a value of zero. This means that we can report on all of the errors in a file, not just the first one. MCContext::reportError records the fact that an error was encountered, so we won't actually emit an object file with the incorrect contents. Differential Revision: http://reviews.llvm.org/D14717 llvm-svn: 253328
2015-11-17 18:00:43 +08:00
// CHECK: :[[@LINE+1]]:{{[0-9]+}}: error: expected relocatable expression
.word -undef
// CHECK: :[[@LINE+1]]:{{[0-9]+}}: error: No relocation available to represent this relative expression
adr x0, #a-undef
// CHECK: :[[@LINE+1]]:{{[0-9]+}}: error: Cannot represent a difference across sections
.word x_a - y_a
[AArch64] Replace some uses of report_fatal_error with reportError in AArch64 ELF object writer If we can't handle a relocation type, report it as an error in the source, rather than asserting. I've added a more descriptive message and a test for the only cases of this that I've been able to trigger. Differential Revision: http://reviews.llvm.org/D18388 llvm-svn: 264156
2016-03-23 21:45:03 +08:00
// CHECK: :[[@LINE+1]]:{{[0-9]+}}: error: 1-byte data relocations not supported
.byte undef
// CHECK: :[[@LINE+1]]:{{[0-9]+}}: error: 1-byte data relocations not supported
.byte undef-.
// CHECK: :[[@LINE+1]]:{{[0-9]+}}: error: Unsupported pc-relative fixup kind
ldr x0, [x1, :lo12:undef-.]
// CHECK: :[[@LINE+1]]:{{[0-9]+}}: error: invalid fixup for 8-bit load/store instruction
ldrb w0, [x1, :gottprel_lo12:undef]
// CHECK: :[[@LINE+1]]:{{[0-9]+}}: error: invalid fixup for 16-bit load/store instruction
ldrh w0, [x1, :gottprel_lo12:undef]
[AArch64] ILP32 Backend Relocation Support Remove "_NC" suffix and semantics from TLSDESC_LD{64,32}_LO12 and TLSDESC_ADD_LO12 relocations Rearrange ordering in AArch64.def to follow relocation encoding Fix name: R_AARCH64_P32_LD64_GOT_LO12_NC => R_AARCH64_P32_LD32_GOT_LO12_NC Add support for several "TLS", "TLSGD", and "TLSLD" relocations for ILP32 Fix return values from isNonILP32reloc Add implementations for R_AARCH64_ADR_PREL_PG_HI21_NC, R_AARCH64_P32_LD32_GOT_LO12_NC, R_AARCH64_P32_TLSIE_LD32_GOTTPREL_LO12_NC, R_AARCH64_P32_TLSDESC_LD32_LO12, R_AARCH64_LD64_GOT_LO12_NC, *TLSLD_LDST128_DTPREL_LO12, *TLSLD_LDST128_DTPREL_LO12_NC, *TLSLE_LDST128_TPREL_LO12, *TLSLE_LDST128_TPREL_LO12_NC Modify error messages to give name of equivalent relocation in the ABI not being used, along with better checking for non-existent requested relocations. Added assembler support for "pg_hi21_nc" Relocation definitions added without implementations: R_AARCH64_P32_TLSDESC_ADR_PREL21, R_AARCH64_P32_TLSGD_ADR_PREL21, R_AARCH64_P32_TLSGD_ADD_LO12_NC, R_AARCH64_P32_TLSLD_ADR_PREL21, R_AARCH64_P32_TLSLD_ADR_PAGE21, R_AARCH64_P32_TLSLD_ADD_LO12_NC, R_AARCH64_P32_TLSLD_LD_PREL19, R_AARCH64_P32_TLSDESC_LD_PREL19, R_AARCH64_P32_TLSGD_ADR_PAGE21, R_AARCH64_P32_TLS_DTPREL, R_AARCH64_P32_TLS_DTPMOD, R_AARCH64_P32_TLS_TPREL, R_AARCH64_P32_TLSDESC Fix encoding: R_AARCH64_P32_TLSDESC_ADR_PAGE21 Reviewers: Peter Smith Patch by: Joel Jones (jjones@cavium.com) Differential Revision: https://reviews.llvm.org/D32072 llvm-svn: 301980
2017-05-03 06:01:48 +08:00
// CHECK: :[[@LINE+1]]:{{[0-9]+}}: error: LP64 32-bit load/store relocation not supported (ILP32 eqv: TLSIE_LD32_GOTTPREL_LO12_NC)
[AArch64] Replace some uses of report_fatal_error with reportError in AArch64 ELF object writer If we can't handle a relocation type, report it as an error in the source, rather than asserting. I've added a more descriptive message and a test for the only cases of this that I've been able to trigger. Differential Revision: http://reviews.llvm.org/D18388 llvm-svn: 264156
2016-03-23 21:45:03 +08:00
ldr w0, [x1, :gottprel_lo12:undef]
[Assembler] Make fatal assembler errors non-fatal Currently, if the assembler encounters an error after parsing (such as an out-of-range fixup), it reports this as a fatal error, and so stops after the first error. However, for most of these there is an obvious way to recover after emitting the error, such as emitting the fixup with a value of zero. This means that we can report on all of the errors in a file, not just the first one. MCContext::reportError records the fact that an error was encountered, so we won't actually emit an object file with the incorrect contents. Differential Revision: http://reviews.llvm.org/D14717 llvm-svn: 253328
2015-11-17 18:00:43 +08:00
w:
.word 0
.weak w
.section sec_x
x_a:
.word 0
.section sec_y
y_a:
.word 0