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/ELF/gen-dwarf.s

47 lines
1.4 KiB
ArmAsm
Raw Normal View History

Replace coff-/elf-dump with llvm-readobj llvm-svn: 179361
2013-04-12 12:06:46 +08:00
// RUN: llvm-mc -g -triple i686-pc-linux-gnu %s -filetype=obj -o - | llvm-readobj -r | FileCheck %s
DebugInfo: Emit relocation to debug_line section when emitting asm for asm I don't think this is reachable by any frontend (why would you transform asm to asm+debug info?) but it helps tidy up some of this code, avoid the weird special case of "emit the first CU, store the label, then emit the rest" in MCDwarfLineTable::Emit by instead having the DWARF-for-assembly case use the same codepath as DwarfDebug.cpp, by registering the label of the debug_line section, thus causing it to be emitted. (with a special case in asm output to just emit the label since asm output uses the .loc directives, etc, rather than the debug_loc directly) llvm-svn: 205286
2014-04-01 15:35:52 +08:00
// RUN: llvm-mc -g -triple i686-pc-linux-gnu %s -filetype=asm -o - | FileCheck --check-prefix=ASM %s
On ELF, create relocations to the abbreviation and line sections when producing debug info for assembly files. We were already doing the right thing when producing debug info for C/C++. ELF linkers don't know dwarf, so they depend on these relocations to produce valid dwarf output. llvm-svn: 151655
2012-02-29 05:13:05 +08:00
Emit relocations from .debug_aranges to .debug_info for asm files llvm-svn: 167926
2012-11-14 17:55:38 +08:00
// Test that on ELF:
// 1. the debug info has a relocation to debug_abbrev and one to to debug_line.
// 2. the debug_aranges has relocations to text and debug_line.
On ELF, create relocations to the abbreviation and line sections when producing debug info for assembly files. We were already doing the right thing when producing debug info for C/C++. ELF linkers don't know dwarf, so they depend on these relocations to produce valid dwarf output. llvm-svn: 151655
2012-02-29 05:13:05 +08:00
.text
.globl foo
.type foo, @function
.align 4
foo:
ret
.size foo, .-foo
Replace coff-/elf-dump with llvm-readobj llvm-svn: 179361
2013-04-12 12:06:46 +08:00
// CHECK: Relocations [
Change how we iterate over relocations on ELF. For COFF and MachO, sections semantically have relocations that apply to them. That is not the case on ELF. In relocatable objects (.o), a section with relocations in ELF has offsets to another section where the relocations should be applied. In dynamic objects and executables, relocations don't have an offset, they have a virtual address. The section sh_info may or may not point to another section, but that is not actually used for resolving the relocations. This patch exposes that in the ObjectFile API. It has the following advantages: * Most (all?) clients can handle this more efficiently. They will normally walk all relocations, so doing an effort to iterate in a particular order doesn't save time. * llvm-readobj now prints relocations in the same way the native readelf does. * probably most important, relocations that don't point to any section are now visible. This is the case of relocations in the rela.dyn section. See the updated relocation-executable.test for example. llvm-svn: 182908
2013-05-30 11:05:14 +08:00
// CHECK: Section ({{[^ ]+}}) .rel.debug_info {
Replace coff-/elf-dump with llvm-readobj llvm-svn: 179361
2013-04-12 12:06:46 +08:00
// CHECK-NEXT: 0x6 R_386_32 .debug_abbrev 0x0
// CHECK-NEXT: 0xC R_386_32 .debug_line 0x0
// CHECK: }
Change how we iterate over relocations on ELF. For COFF and MachO, sections semantically have relocations that apply to them. That is not the case on ELF. In relocatable objects (.o), a section with relocations in ELF has offsets to another section where the relocations should be applied. In dynamic objects and executables, relocations don't have an offset, they have a virtual address. The section sh_info may or may not point to another section, but that is not actually used for resolving the relocations. This patch exposes that in the ObjectFile API. It has the following advantages: * Most (all?) clients can handle this more efficiently. They will normally walk all relocations, so doing an effort to iterate in a particular order doesn't save time. * llvm-readobj now prints relocations in the same way the native readelf does. * probably most important, relocations that don't point to any section are now visible. This is the case of relocations in the rela.dyn section. See the updated relocation-executable.test for example. llvm-svn: 182908
2013-05-30 11:05:14 +08:00
// CHECK-NEXT: Section ({{[^ ]+}}) .rel.debug_aranges {
Replace coff-/elf-dump with llvm-readobj llvm-svn: 179361
2013-04-12 12:06:46 +08:00
// CHECK-NEXT: 0x6 R_386_32 .debug_info 0x0
// CHECK-NEXT: 0x10 R_386_32 .text 0x0
// CHECK-NEXT: }
DebugInfo: Emit relocation to debug_line section when emitting asm for asm I don't think this is reachable by any frontend (why would you transform asm to asm+debug info?) but it helps tidy up some of this code, avoid the weird special case of "emit the first CU, store the label, then emit the rest" in MCDwarfLineTable::Emit by instead having the DWARF-for-assembly case use the same codepath as DwarfDebug.cpp, by registering the label of the debug_line section, thus causing it to be emitted. (with a special case in asm output to just emit the label since asm output uses the .loc directives, etc, rather than the debug_loc directly) llvm-svn: 205286
2014-04-01 15:35:52 +08:00
// CHECK: ]
// First instance of the section is just to give it a label for debug_aranges to refer to
// ASM: .section .debug_info
// ASM: .section .debug_abbrev
// ASM-NEXT: [[ABBREV_LABEL:.Ltmp[0-9]+]]
// Second instance of the section has the CU
// ASM: .section .debug_info
// Dwarf version
// ASM: .short 2
// ASM-NEXT: .long [[ABBREV_LABEL]]
// First .byte 1 is the abbreviation number for the compile_unit abbrev
// ASM: .byte 1
// ASM-NEXT: .long [[LINE_LABEL:.Ltmp[0-9]+]]
// ASM: .section .debug_line
// ASM-NEXT: [[LINE_LABEL]]