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/COFF/symbol-fragment-offset-64.s

167 lines
5.7 KiB
ArmAsm
Raw Normal View History

Replace coff-/elf-dump with llvm-readobj llvm-svn: 179361
2013-04-12 12:06:46 +08:00
// The purpose of this test is to see if the COFF object writer is emitting the
// proper relocations for multiple pieces of data in a single data fragment.
// RUN: llvm-mc -filetype=obj -triple x86_64-pc-win32 %s | llvm-readobj -h -s -sr -sd -t | FileCheck %s
.def _main;
.scl 2;
.type 32;
.endef
.text
.globl _main
.align 16, 0x90
_main: # @main
# BB#0: # %entry
subl $4, %esp
movl $.L_.str0, (%esp)
callq _printf
movl $.L_.str1, (%esp)
callq _puts
movl $.L_.str2, (%esp)
callq _puts
xorl %eax, %eax
addl $4, %esp
ret
.data
.L_.str0: # @.str0
.asciz "Hello "
.L_.str1: # @.str1
.asciz "World!"
.align 16 # @.str2
.L_.str2:
.asciz "I'm The Last Line."
// CHECK: {
// CHECK: Machine: IMAGE_FILE_MACHINE_AMD64
MC: prevent early DCE of empty sections Prevent the early elimination of sections in the object writer. There may be references to the section itself by other symbols, which may potentially not be possible to resolve. ML (Visual Studio's Macro Assembler) also seems to retain empty sections. The elimination of symbols and sections which are unused should really occur at the link phase. This will not cause any change in the resulting binary, simply in the generated object files. The adjustments to the other unit tests account for the fluctuating section index caused by the appearance of sections which were previously discarded. llvm-svn: 210373
2014-06-07 05:40:16 +08:00
// CHECK: SectionCount: 3
Replace coff-/elf-dump with llvm-readobj llvm-svn: 179361
2013-04-12 12:06:46 +08:00
// CHECK: TimeDateStamp: {{[0-9]+}}
// CHECK: PointerToSymbolTable: 0x{{[0-9A-F]+}}
MC: prevent early DCE of empty sections Prevent the early elimination of sections in the object writer. There may be references to the section itself by other symbols, which may potentially not be possible to resolve. ML (Visual Studio's Macro Assembler) also seems to retain empty sections. The elimination of symbols and sections which are unused should really occur at the link phase. This will not cause any change in the resulting binary, simply in the generated object files. The adjustments to the other unit tests account for the fluctuating section index caused by the appearance of sections which were previously discarded. llvm-svn: 210373
2014-06-07 05:40:16 +08:00
// CHECK: SymbolCount: 9
Replace coff-/elf-dump with llvm-readobj llvm-svn: 179361
2013-04-12 12:06:46 +08:00
// CHECK: OptionalHeaderSize: 0
// CHECK: Characteristics [ (0x0)
// CHECK: ]
// CHECK: }
// CHECK: Sections [
// CHECK: Section {
// CHECK: Number: 1
// CHECK: Name: .text
// CHECK: VirtualSize: 0
// CHECK: VirtualAddress: 0
// CHECK: RawDataSize: {{[0-9]+}}
// CHECK: PointerToRawData: 0x{{[0-9A-F]+}}
// CHECK: PointerToRelocations: 0x{{[0-9A-F]+}}
// CHECK: PointerToLineNumbers: 0x0
// CHECK: RelocationCount: 6
// CHECK: LineNumberCount: 0
// CHECK: Characteristics [ (0x60500020)
// CHECK: IMAGE_SCN_ALIGN_16BYTES
// CHECK: IMAGE_SCN_CNT_CODE
// CHECK: IMAGE_SCN_MEM_EXECUTE
// CHECK: IMAGE_SCN_MEM_READ
// CHECK: ]
// CHECK: Relocations [
// CHECK: 0x7 IMAGE_REL_AMD64_ADDR32 .data
// CHECK: 0xC IMAGE_REL_AMD64_REL32 _printf
// CHECK: 0x14 IMAGE_REL_AMD64_ADDR32 .data
// CHECK: 0x19 IMAGE_REL_AMD64_REL32 _puts
// CHECK: 0x21 IMAGE_REL_AMD64_ADDR32 .data
// CHECK: 0x26 IMAGE_REL_AMD64_REL32 _puts
// CHECK: ]
// CHECK: SectionData (
// CHECK: 0000: 83EC0467 C7042400 000000E8 00000000
// CHECK: 0010: 67C70424 07000000 E8000000 0067C704
// CHECK: 0020: 24100000 00E80000 000031C0 83C404C3
// CHECK: )
// CHECK: }
// CHECK: Section {
// CHECK: Number: 2
// CHECK: Name: .data
// CHECK: VirtualSize: 0
// CHECK: VirtualAddress: 0
// CHECK: RawDataSize: {{[0-9]+}}
// CHECK: PointerToRawData: 0x{{[0-9A-F]+}}
// CHECK: PointerToRelocations: 0x0
// CHECK: PointerToLineNumbers: 0x0
// CHECK: RelocationCount: 0
// CHECK: LineNumberCount: 0
// CHECK: Characteristics [ (0xC0500040)
// CHECK: IMAGE_SCN_ALIGN_16BYTES
// CHECK: IMAGE_SCN_CNT_INITIALIZED_DATA
// CHECK: IMAGE_SCN_MEM_READ
// CHECK: IMAGE_SCN_MEM_WRITE
// CHECK: Relocations [
// CHECK: ]
// CHECK: SectionData (
// CHECK: 0000: 48656C6C 6F200057 6F726C64 21000000 |Hello .World!...|
// CHECK: 0010: 49276D20 54686520 4C617374 204C696E |I'm The Last Lin|
// CHECK: 0020: 652E00 |e..|
// CHECK: )
// CHECK: }
// CHECK: ]
// CHECK: Symbols [
// CHECK: Symbol {
// CHECK: Name: .text
// CHECK: Value: 0
// CHECK: Section: .text
// CHECK: BaseType: Null
// CHECK: ComplexType: Null
// CHECK: StorageClass: Static
// CHECK: AuxSymbolCount: 1
// CHECK: AuxSectionDef {
// CHECK: Length: 48
// CHECK: RelocationCount: 6
// CHECK: LineNumberCount: 0
[MC] Add support for generating COFF CRCs COFF sections are accompanied with an auxiliary symbol which includes a checksum. This checksum used to be filled with just zero but this seems to upset LINK.exe when it is processing a /INCREMENTAL link job. Instead, fill the CheckSum field with the JamCRC of the section contents. This matches MSVC's behavior. This fixes PR19666. N.B. A rather simple implementation of JamCRC is given. It implements a byte-wise calculation using the method given by Sarwate. There are implementations with higher throughput like slice-by-eight and making use of PCLMULQDQ. We can switch to one of those techniques if it turns out to be a significant use of time. llvm-svn: 246590
2015-09-02 05:23:58 +08:00
// CHECK: Checksum: 0x7BD396E3
Replace coff-/elf-dump with llvm-readobj llvm-svn: 179361
2013-04-12 12:06:46 +08:00
// CHECK: Number: 1
// CHECK: Selection: 0x0
// CHECK: }
// CHECK: }
// CHECK: Symbol {
// CHECK: Name: .data
// CHECK: Value: 0
// CHECK: Section: .data
// CHECK: BaseType: Null
// CHECK: ComplexType: Null
// CHECK: StorageClass: Static
// CHECK: AuxSymbolCount: 1
// CHECK: AuxSectionDef {
// CHECK: Length: 35
// CHECK: RelocationCount: 0
// CHECK: LineNumberCount: 0
[MC] Add support for generating COFF CRCs COFF sections are accompanied with an auxiliary symbol which includes a checksum. This checksum used to be filled with just zero but this seems to upset LINK.exe when it is processing a /INCREMENTAL link job. Instead, fill the CheckSum field with the JamCRC of the section contents. This matches MSVC's behavior. This fixes PR19666. N.B. A rather simple implementation of JamCRC is given. It implements a byte-wise calculation using the method given by Sarwate. There are implementations with higher throughput like slice-by-eight and making use of PCLMULQDQ. We can switch to one of those techniques if it turns out to be a significant use of time. llvm-svn: 246590
2015-09-02 05:23:58 +08:00
// CHECK: Checksum: 0xB0A4C21
Replace coff-/elf-dump with llvm-readobj llvm-svn: 179361
2013-04-12 12:06:46 +08:00
// CHECK: Number: 2
// CHECK: Selection: 0x0
// CHECK: }
// CHECK: }
// CHECK: Symbol {
// CHECK: Name: _main
// CHECK: Value: 0
// CHECK: Section: .text
// CHECK: BaseType: Null
// CHECK: ComplexType: Function
// CHECK: StorageClass: External
// CHECK: AuxSymbolCount: 0
// CHECK: }
// CHECK: Symbol {
// CHECK: Name: _printf
// CHECK: Value: 0
llvm-readobj: pretty-print special COFF section names Print IMAGE_SYM_DEBUG and the like instead of (-2). llvm-svn: 218172
2014-09-20 08:25:06 +08:00
// CHECK: Section: IMAGE_SYM_UNDEFINED (0)
Replace coff-/elf-dump with llvm-readobj llvm-svn: 179361
2013-04-12 12:06:46 +08:00
// CHECK: BaseType: Null
// CHECK: ComplexType: Null
// CHECK: StorageClass: External
// CHECK: AuxSymbolCount: 0
// CHECK: }
// CHECK: Symbol {
// CHECK: Name: _puts
// CHECK: Value: 0
llvm-readobj: pretty-print special COFF section names Print IMAGE_SYM_DEBUG and the like instead of (-2). llvm-svn: 218172
2014-09-20 08:25:06 +08:00
// CHECK: Section: IMAGE_SYM_UNDEFINED (0)
Replace coff-/elf-dump with llvm-readobj llvm-svn: 179361
2013-04-12 12:06:46 +08:00
// CHECK: BaseType: Null
// CHECK: ComplexType: Null
// CHECK: StorageClass: External
// CHECK: AuxSymbolCount: 0
// CHECK: }
// CHECK: ]