maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/tools/llvm-readobj/relocations.test

174 lines
6.2 KiB
Plaintext
Raw Normal View History

Implements low-level object file format specific output for COFF and ELF with support for: - File headers - Section headers + data - Relocations - Symbols - Unwind data (only COFF/Win64) The output format follows a few rules: - Values are almost always output one per line (as elf-dump/coff-dump already do). - Many values are translated to something readable (like enum names), with the raw value in parentheses. - Hex numbers are output in uppercase, prefixed with "0x". - Flags are sorted alphabetically. - Lists and groups are always delimited. Example output: ---------- snip ---------- Sections [ Section { Index: 1 Name: .text (5) Type: SHT_PROGBITS (0x1) Flags [ (0x6) SHF_ALLOC (0x2) SHF_EXECINSTR (0x4) ] Address: 0x0 Offset: 0x40 Size: 33 Link: 0 Info: 0 AddressAlignment: 16 EntrySize: 0 Relocations [ 0x6 R_386_32 .rodata.str1.1 0x0 0xB R_386_PC32 puts 0x0 0x12 R_386_32 .rodata.str1.1 0x0 0x17 R_386_PC32 puts 0x0 ] SectionData ( 0000: 83EC04C7 04240000 0000E8FC FFFFFFC7 |.....$..........| 0010: 04240600 0000E8FC FFFFFF31 C083C404 |.$.........1....| 0020: C3 |.| ) } ] ---------- snip ---------- Relocations and symbols can be output standalone or together with the section header as displayed in the example. This feature set supports all tests in test/MC/COFF and test/MC/ELF (and I suspect all additional tests using elf-dump), making elf-dump and coff-dump deprecated. Patch by Nico Rieck! llvm-svn: 178679
2013-04-04 02:31:38 +08:00
RUN: llvm-readobj -r %p/Inputs/trivial.obj.coff-i386 \
RUN: | FileCheck %s -check-prefix COFF
RUN: llvm-readobj -r %p/Inputs/trivial.obj.elf-i386 \
RUN: | FileCheck %s -check-prefix ELF
RUN: llvm-readobj -r %p/Inputs/trivial.obj.macho-i386 \
Add MachO-x86-64 tests. The object was already checked in, but was not being tested. llvm-svn: 179256
2013-04-11 10:52:29 +08:00
RUN: | FileCheck %s -check-prefix MACHO-I386
RUN: llvm-readobj -r %p/Inputs/trivial.obj.macho-x86-64 \
RUN: | FileCheck %s -check-prefix MACHO-X86-64
Finish templating MachObjectFile over endianness. We are now able to handle big endian macho files in llvm-readobject. Thanks to David Fang for providing the object files. llvm-svn: 179440
2013-04-13 09:45:40 +08:00
RUN: llvm-readobj -r %p/Inputs/trivial.obj.macho-ppc \
RUN: | FileCheck %s -check-prefix MACHO-PPC
RUN: llvm-readobj -r %p/Inputs/trivial.obj.macho-ppc64 \
RUN: | FileCheck %s -check-prefix MACHO-PPC64
At Jim Grosbach's request detemplate Object/MachO.h. We are still able to handle mixed endian objects by swapping one struct at a time. llvm-svn: 179778
2013-04-19 02:08:55 +08:00
RUN: llvm-readobj -r -expand-relocs %p/Inputs/trivial.obj.macho-arm \
RUN: | FileCheck %s -check-prefix MACHO-ARM
Implements low-level object file format specific output for COFF and ELF with support for: - File headers - Section headers + data - Relocations - Symbols - Unwind data (only COFF/Win64) The output format follows a few rules: - Values are almost always output one per line (as elf-dump/coff-dump already do). - Many values are translated to something readable (like enum names), with the raw value in parentheses. - Hex numbers are output in uppercase, prefixed with "0x". - Flags are sorted alphabetically. - Lists and groups are always delimited. Example output: ---------- snip ---------- Sections [ Section { Index: 1 Name: .text (5) Type: SHT_PROGBITS (0x1) Flags [ (0x6) SHF_ALLOC (0x2) SHF_EXECINSTR (0x4) ] Address: 0x0 Offset: 0x40 Size: 33 Link: 0 Info: 0 AddressAlignment: 16 EntrySize: 0 Relocations [ 0x6 R_386_32 .rodata.str1.1 0x0 0xB R_386_PC32 puts 0x0 0x12 R_386_32 .rodata.str1.1 0x0 0x17 R_386_PC32 puts 0x0 ] SectionData ( 0000: 83EC04C7 04240000 0000E8FC FFFFFFC7 |.....$..........| 0010: 04240600 0000E8FC FFFFFF31 C083C404 |.$.........1....| 0020: C3 |.| ) } ] ---------- snip ---------- Relocations and symbols can be output standalone or together with the section header as displayed in the example. This feature set supports all tests in test/MC/COFF and test/MC/ELF (and I suspect all additional tests using elf-dump), making elf-dump and coff-dump deprecated. Patch by Nico Rieck! llvm-svn: 178679
2013-04-04 02:31:38 +08:00
COFF: Relocations [
COFF-NEXT: Section (1) .text {
COFF-NEXT: 0x4 IMAGE_REL_I386_DIR32 .data
COFF-NEXT: 0x9 IMAGE_REL_I386_REL32 _puts
COFF-NEXT: 0xE IMAGE_REL_I386_REL32 _SomeOtherFunction
COFF-NEXT: }
COFF-NEXT: ]
ELF: 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
ELF-NEXT: Section (2) .rel.text {
Implements low-level object file format specific output for COFF and ELF with support for: - File headers - Section headers + data - Relocations - Symbols - Unwind data (only COFF/Win64) The output format follows a few rules: - Values are almost always output one per line (as elf-dump/coff-dump already do). - Many values are translated to something readable (like enum names), with the raw value in parentheses. - Hex numbers are output in uppercase, prefixed with "0x". - Flags are sorted alphabetically. - Lists and groups are always delimited. Example output: ---------- snip ---------- Sections [ Section { Index: 1 Name: .text (5) Type: SHT_PROGBITS (0x1) Flags [ (0x6) SHF_ALLOC (0x2) SHF_EXECINSTR (0x4) ] Address: 0x0 Offset: 0x40 Size: 33 Link: 0 Info: 0 AddressAlignment: 16 EntrySize: 0 Relocations [ 0x6 R_386_32 .rodata.str1.1 0x0 0xB R_386_PC32 puts 0x0 0x12 R_386_32 .rodata.str1.1 0x0 0x17 R_386_PC32 puts 0x0 ] SectionData ( 0000: 83EC04C7 04240000 0000E8FC FFFFFFC7 |.....$..........| 0010: 04240600 0000E8FC FFFFFF31 C083C404 |.$.........1....| 0020: C3 |.| ) } ] ---------- snip ---------- Relocations and symbols can be output standalone or together with the section header as displayed in the example. This feature set supports all tests in test/MC/COFF and test/MC/ELF (and I suspect all additional tests using elf-dump), making elf-dump and coff-dump deprecated. Patch by Nico Rieck! llvm-svn: 178679
2013-04-04 02:31:38 +08:00
ELF-NEXT: 0xC R_386_GOTPC _GLOBAL_OFFSET_TABLE_ 0x0
ELF-NEXT: 0x12 R_386_GOTOFF .L.str 0x0
ELF-NEXT: 0x1A R_386_PLT32 puts 0x0
ELF-NEXT: 0x1F R_386_PLT32 SomeOtherFunction 0x0
ELF-NEXT: }
ELF-NEXT: ]
Add MachO-x86-64 tests. The object was already checked in, but was not being tested. llvm-svn: 179256
2013-04-11 10:52:29 +08:00
MACHO-I386: Relocations [
MACHO-I386-NEXT: Section __text {
Add 179294 back, but don't use bit fields so that it works on big endian hosts. Original message: Print more information about relocations. With this patch llvm-readobj now prints if a relocation is pcrel, its length, if it is extern and if it is scattered. It also refactors the code a bit to use bit fields instead of shifts and masks all over the place. llvm-svn: 179345
2013-04-12 08:17:33 +08:00
MACHO-I386-NEXT: 0x18 1 2 1 GENERIC_RELOC_VANILLA 0 _SomeOtherFunction
MACHO-I386-NEXT: 0x13 1 2 1 GENERIC_RELOC_VANILLA 0 _puts
llvm-readobj: fix MachO relocatoin printing a bit. There were two issues here: 1. At the very least, scattered relocations cannot use the same code to determine the corresponding symbol being referred to. For some reason we pretend there is no symbol, even when one actually exists in the symtab, so to match this behaviour getRelocationSymbol should simply return symbols_end for scattered relocations. 2. Printing "-" when we can't get a symbol (including the scattered case, but not exclusively), isn't that helpful. In both cases there *is* interesting information in that field, so we should print it. As hex will do. Small part of rdar://problem/17553104 llvm-svn: 212332
2014-07-04 18:57:56 +08:00
MACHO-I386-NEXT: 0xB 0 2 n/a GENERIC_RELOC_LOCAL_SECTDIFF 1 0x22
MACHO-I386-NEXT: 0x0 0 2 n/a GENERIC_RELOC_PAIR 1 0x8
Add MachO-x86-64 tests. The object was already checked in, but was not being tested. llvm-svn: 179256
2013-04-11 10:52:29 +08:00
MACHO-I386-NEXT: }
MACHO-I386-NEXT: ]
MACHO-X86-64: Relocations [
MACHO-X86-64-NEXT: Section __text {
Add 179294 back, but don't use bit fields so that it works on big endian hosts. Original message: Print more information about relocations. With this patch llvm-readobj now prints if a relocation is pcrel, its length, if it is extern and if it is scattered. It also refactors the code a bit to use bit fields instead of shifts and masks all over the place. llvm-svn: 179345
2013-04-12 08:17:33 +08:00
MACHO-X86-64-NEXT: 0xE 1 2 1 X86_64_RELOC_BRANCH 0 _SomeOtherFunction
MACHO-X86-64-NEXT: 0x9 1 2 1 X86_64_RELOC_BRANCH 0 _puts
MACHO-X86-64-NEXT: 0x4 1 2 1 X86_64_RELOC_SIGNED 0 L_.str
Add MachO-x86-64 tests. The object was already checked in, but was not being tested. llvm-svn: 179256
2013-04-11 10:52:29 +08:00
MACHO-X86-64-NEXT: }
MACHO-X86-64-NEXT:]
Finish templating MachObjectFile over endianness. We are now able to handle big endian macho files in llvm-readobject. Thanks to David Fang for providing the object files. llvm-svn: 179440
2013-04-13 09:45:40 +08:00
MACHO-PPC: Relocations [
MACHO-PPC-NEXT: Section __text {
llvm-readobj: fix MachO relocatoin printing a bit. There were two issues here: 1. At the very least, scattered relocations cannot use the same code to determine the corresponding symbol being referred to. For some reason we pretend there is no symbol, even when one actually exists in the symtab, so to match this behaviour getRelocationSymbol should simply return symbols_end for scattered relocations. 2. Printing "-" when we can't get a symbol (including the scattered case, but not exclusively), isn't that helpful. In both cases there *is* interesting information in that field, so we should print it. As hex will do. Small part of rdar://problem/17553104 llvm-svn: 212332
2014-07-04 18:57:56 +08:00
MACHO-PPC-NEXT: 0x24 0 2 n/a PPC_RELOC_LO16_SECTDIFF 1 0x64
MACHO-PPC-NEXT: 0x0 0 2 n/a PPC_RELOC_PAIR 1 0xC
MACHO-PPC-NEXT: 0x1C 0 2 n/a PPC_RELOC_HA16_SECTDIFF 1 0x64
MACHO-PPC-NEXT: 0x58 0 2 n/a PPC_RELOC_PAIR 1 0xC
MACHO-PPC-NEXT: 0x18 1 2 0 PPC_RELOC_BR24 0 0x2
Finish templating MachObjectFile over endianness. We are now able to handle big endian macho files in llvm-readobject. Thanks to David Fang for providing the object files. llvm-svn: 179440
2013-04-13 09:45:40 +08:00
MACHO-PPC-NEXT: }
MACHO-PPC-NEXT: Section __picsymbolstub1 {
llvm-readobj: fix MachO relocatoin printing a bit. There were two issues here: 1. At the very least, scattered relocations cannot use the same code to determine the corresponding symbol being referred to. For some reason we pretend there is no symbol, even when one actually exists in the symtab, so to match this behaviour getRelocationSymbol should simply return symbols_end for scattered relocations. 2. Printing "-" when we can't get a symbol (including the scattered case, but not exclusively), isn't that helpful. In both cases there *is* interesting information in that field, so we should print it. As hex will do. Small part of rdar://problem/17553104 llvm-svn: 212332
2014-07-04 18:57:56 +08:00
MACHO-PPC-NEXT: 0x14 0 2 n/a PPC_RELOC_LO16_SECTDIFF 1 0x68
MACHO-PPC-NEXT: 0x0 0 2 n/a PPC_RELOC_PAIR 1 0x48
MACHO-PPC-NEXT: 0xC 0 2 n/a PPC_RELOC_HA16_SECTDIFF 1 0x68
MACHO-PPC-NEXT: 0x20 0 2 n/a PPC_RELOC_PAIR 1 0x48
Finish templating MachObjectFile over endianness. We are now able to handle big endian macho files in llvm-readobject. Thanks to David Fang for providing the object files. llvm-svn: 179440
2013-04-13 09:45:40 +08:00
MACHO-PPC-NEXT: }
MACHO-PPC-NEXT: Section __la_symbol_ptr {
MACHO-PPC-NEXT: 0x0 0 2 1 PPC_RELOC_VANILLA 0 dyld_stub_binding_helper
MACHO-PPC-NEXT: }
MACHO-PPC-NEXT: ]
MACHO-PPC64: Relocations [
MACHO-PPC64-NEXT: Section __text {
llvm-readobj: fix MachO relocatoin printing a bit. There were two issues here: 1. At the very least, scattered relocations cannot use the same code to determine the corresponding symbol being referred to. For some reason we pretend there is no symbol, even when one actually exists in the symtab, so to match this behaviour getRelocationSymbol should simply return symbols_end for scattered relocations. 2. Printing "-" when we can't get a symbol (including the scattered case, but not exclusively), isn't that helpful. In both cases there *is* interesting information in that field, so we should print it. As hex will do. Small part of rdar://problem/17553104 llvm-svn: 212332
2014-07-04 18:57:56 +08:00
MACHO-PPC64-NEXT: 0x24 0 2 n/a 1 0x64
MACHO-PPC64-NEXT: 0x0 0 2 n/a 1 0xC
MACHO-PPC64-NEXT: 0x1C 0 2 n/a 1 0x64
MACHO-PPC64-NEXT: 0x58 0 2 n/a 1 0xC
MACHO-PPC64-NEXT: 0x18 1 2 0 0 0x2
Finish templating MachObjectFile over endianness. We are now able to handle big endian macho files in llvm-readobject. Thanks to David Fang for providing the object files. llvm-svn: 179440
2013-04-13 09:45:40 +08:00
MACHO-PPC64-NEXT: }
MACHO-PPC64-NEXT: Section __picsymbolstub1 {
llvm-readobj: fix MachO relocatoin printing a bit. There were two issues here: 1. At the very least, scattered relocations cannot use the same code to determine the corresponding symbol being referred to. For some reason we pretend there is no symbol, even when one actually exists in the symtab, so to match this behaviour getRelocationSymbol should simply return symbols_end for scattered relocations. 2. Printing "-" when we can't get a symbol (including the scattered case, but not exclusively), isn't that helpful. In both cases there *is* interesting information in that field, so we should print it. As hex will do. Small part of rdar://problem/17553104 llvm-svn: 212332
2014-07-04 18:57:56 +08:00
MACHO-PPC64-NEXT: 0x14 0 2 n/a 1 0x6C
MACHO-PPC64-NEXT: 0x0 0 2 n/a 1 0x48
MACHO-PPC64-NEXT: 0xC 0 2 n/a 1 0x6C
MACHO-PPC64-NEXT: 0x24 0 2 n/a 1 0x48
Finish templating MachObjectFile over endianness. We are now able to handle big endian macho files in llvm-readobject. Thanks to David Fang for providing the object files. llvm-svn: 179440
2013-04-13 09:45:40 +08:00
MACHO-PPC64-NEXT: }
MACHO-PPC64-NEXT: Section __la_symbol_ptr {
MACHO-PPC64-NEXT: 0x0 0 3 1 0 dyld_stub_binding_helper
MACHO-PPC64-NEXT: }
MACHO-PPC64-NEXT: ]
At Jim Grosbach's request detemplate Object/MachO.h. We are still able to handle mixed endian objects by swapping one struct at a time. llvm-svn: 179778
2013-04-19 02:08:55 +08:00
MACHO-ARM: Relocations [
MACHO-ARM-NEXT: Section __text {
MACHO-ARM-NEXT: Relocation {
MACHO-ARM-NEXT: Offset: 0x38
MACHO-ARM-NEXT: PCRel: 0
MACHO-ARM-NEXT: Length: 2
MACHO-ARM-NEXT: Extern: N/A
MACHO-ARM-NEXT: Type: ARM_RELOC_SECTDIFF (2)
llvm-readobj: fix MachO relocatoin printing a bit. There were two issues here: 1. At the very least, scattered relocations cannot use the same code to determine the corresponding symbol being referred to. For some reason we pretend there is no symbol, even when one actually exists in the symtab, so to match this behaviour getRelocationSymbol should simply return symbols_end for scattered relocations. 2. Printing "-" when we can't get a symbol (including the scattered case, but not exclusively), isn't that helpful. In both cases there *is* interesting information in that field, so we should print it. As hex will do. Small part of rdar://problem/17553104 llvm-svn: 212332
2014-07-04 18:57:56 +08:00
MACHO-ARM-NEXT: Symbol: 0x40
At Jim Grosbach's request detemplate Object/MachO.h. We are still able to handle mixed endian objects by swapping one struct at a time. llvm-svn: 179778
2013-04-19 02:08:55 +08:00
MACHO-ARM-NEXT: Scattered: 1
MACHO-ARM-NEXT: }
MACHO-ARM-NEXT: Relocation {
MACHO-ARM-NEXT: Offset: 0x0
MACHO-ARM-NEXT: PCRel: 0
MACHO-ARM-NEXT: Length: 2
MACHO-ARM-NEXT: Extern: N/A
MACHO-ARM-NEXT: Type: ARM_RELOC_PAIR (1)
llvm-readobj: fix MachO relocatoin printing a bit. There were two issues here: 1. At the very least, scattered relocations cannot use the same code to determine the corresponding symbol being referred to. For some reason we pretend there is no symbol, even when one actually exists in the symtab, so to match this behaviour getRelocationSymbol should simply return symbols_end for scattered relocations. 2. Printing "-" when we can't get a symbol (including the scattered case, but not exclusively), isn't that helpful. In both cases there *is* interesting information in that field, so we should print it. As hex will do. Small part of rdar://problem/17553104 llvm-svn: 212332
2014-07-04 18:57:56 +08:00
MACHO-ARM-NEXT: Symbol: 0x28
At Jim Grosbach's request detemplate Object/MachO.h. We are still able to handle mixed endian objects by swapping one struct at a time. llvm-svn: 179778
2013-04-19 02:08:55 +08:00
MACHO-ARM-NEXT: Scattered: 1
MACHO-ARM-NEXT: }
MACHO-ARM-NEXT: Relocation {
MACHO-ARM-NEXT: Offset: 0x20
MACHO-ARM-NEXT: PCRel: 1
MACHO-ARM-NEXT: Length: 2
MACHO-ARM-NEXT: Extern: 1
MACHO-ARM-NEXT: Type: ARM_RELOC_BR24 (5)
MACHO-ARM-NEXT: Symbol: _g
MACHO-ARM-NEXT: Scattered: 0
MACHO-ARM-NEXT: }
MACHO-ARM-NEXT: Relocation {
MACHO-ARM-NEXT: Offset: 0x1C
MACHO-ARM-NEXT: PCRel: 0
MACHO-ARM-NEXT: Length: 1
MACHO-ARM-NEXT: Extern: 1
MACHO-ARM-NEXT: Type: ARM_RELOC_HALF (8)
MACHO-ARM-NEXT: Symbol: _g
MACHO-ARM-NEXT: Scattered: 0
MACHO-ARM-NEXT: }
MACHO-ARM-NEXT: Relocation {
MACHO-ARM-NEXT: Offset: 0x0
MACHO-ARM-NEXT: PCRel: 0
MACHO-ARM-NEXT: Length: 1
MACHO-ARM-NEXT: Extern: 0
MACHO-ARM-NEXT: Type: ARM_RELOC_PAIR (1)
llvm-readobj: fix MachO relocatoin printing a bit. There were two issues here: 1. At the very least, scattered relocations cannot use the same code to determine the corresponding symbol being referred to. For some reason we pretend there is no symbol, even when one actually exists in the symtab, so to match this behaviour getRelocationSymbol should simply return symbols_end for scattered relocations. 2. Printing "-" when we can't get a symbol (including the scattered case, but not exclusively), isn't that helpful. In both cases there *is* interesting information in that field, so we should print it. As hex will do. Small part of rdar://problem/17553104 llvm-svn: 212332
2014-07-04 18:57:56 +08:00
MACHO-ARM-NEXT: Symbol: 0xFFFFFF
At Jim Grosbach's request detemplate Object/MachO.h. We are still able to handle mixed endian objects by swapping one struct at a time. llvm-svn: 179778
2013-04-19 02:08:55 +08:00
MACHO-ARM-NEXT: Scattered: 0
MACHO-ARM-NEXT: }
MACHO-ARM-NEXT: Relocation {
MACHO-ARM-NEXT: Offset: 0x18
MACHO-ARM-NEXT: PCRel: 0
MACHO-ARM-NEXT: Length: 0
MACHO-ARM-NEXT: Extern: 1
MACHO-ARM-NEXT: Type: ARM_RELOC_HALF (8)
MACHO-ARM-NEXT: Symbol: _g
MACHO-ARM-NEXT: Scattered: 0
MACHO-ARM-NEXT: }
MACHO-ARM-NEXT: Relocation {
MACHO-ARM-NEXT: Offset: 0x0
MACHO-ARM-NEXT: PCRel: 0
MACHO-ARM-NEXT: Length: 0
MACHO-ARM-NEXT: Extern: 0
MACHO-ARM-NEXT: Type: ARM_RELOC_PAIR (1)
llvm-readobj: fix MachO relocatoin printing a bit. There were two issues here: 1. At the very least, scattered relocations cannot use the same code to determine the corresponding symbol being referred to. For some reason we pretend there is no symbol, even when one actually exists in the symtab, so to match this behaviour getRelocationSymbol should simply return symbols_end for scattered relocations. 2. Printing "-" when we can't get a symbol (including the scattered case, but not exclusively), isn't that helpful. In both cases there *is* interesting information in that field, so we should print it. As hex will do. Small part of rdar://problem/17553104 llvm-svn: 212332
2014-07-04 18:57:56 +08:00
MACHO-ARM-NEXT: Symbol: 0xFFFFFF
At Jim Grosbach's request detemplate Object/MachO.h. We are still able to handle mixed endian objects by swapping one struct at a time. llvm-svn: 179778
2013-04-19 02:08:55 +08:00
MACHO-ARM-NEXT: Scattered: 0
MACHO-ARM-NEXT: }
MACHO-ARM-NEXT: Relocation {
MACHO-ARM-NEXT: Offset: 0xC
MACHO-ARM-NEXT: PCRel: 0
MACHO-ARM-NEXT: Length: 2
MACHO-ARM-NEXT: Extern: N/A
MACHO-ARM-NEXT: Type: ARM_RELOC_SECTDIFF (2)
llvm-readobj: fix MachO relocatoin printing a bit. There were two issues here: 1. At the very least, scattered relocations cannot use the same code to determine the corresponding symbol being referred to. For some reason we pretend there is no symbol, even when one actually exists in the symtab, so to match this behaviour getRelocationSymbol should simply return symbols_end for scattered relocations. 2. Printing "-" when we can't get a symbol (including the scattered case, but not exclusively), isn't that helpful. In both cases there *is* interesting information in that field, so we should print it. As hex will do. Small part of rdar://problem/17553104 llvm-svn: 212332
2014-07-04 18:57:56 +08:00
MACHO-ARM-NEXT: Symbol: 0x44
At Jim Grosbach's request detemplate Object/MachO.h. We are still able to handle mixed endian objects by swapping one struct at a time. llvm-svn: 179778
2013-04-19 02:08:55 +08:00
MACHO-ARM-NEXT: Scattered: 1
MACHO-ARM-NEXT: }
MACHO-ARM-NEXT: Relocation {
MACHO-ARM-NEXT: Offset: 0x0
MACHO-ARM-NEXT: PCRel: 0
MACHO-ARM-NEXT: Length: 2
MACHO-ARM-NEXT: Extern: N/A
MACHO-ARM-NEXT: Type: ARM_RELOC_PAIR (1)
llvm-readobj: fix MachO relocatoin printing a bit. There were two issues here: 1. At the very least, scattered relocations cannot use the same code to determine the corresponding symbol being referred to. For some reason we pretend there is no symbol, even when one actually exists in the symtab, so to match this behaviour getRelocationSymbol should simply return symbols_end for scattered relocations. 2. Printing "-" when we can't get a symbol (including the scattered case, but not exclusively), isn't that helpful. In both cases there *is* interesting information in that field, so we should print it. As hex will do. Small part of rdar://problem/17553104 llvm-svn: 212332
2014-07-04 18:57:56 +08:00
MACHO-ARM-NEXT: Symbol: 0x4
At Jim Grosbach's request detemplate Object/MachO.h. We are still able to handle mixed endian objects by swapping one struct at a time. llvm-svn: 179778
2013-04-19 02:08:55 +08:00
MACHO-ARM-NEXT: Scattered: 1
MACHO-ARM-NEXT: }
MACHO-ARM-NEXT: }
MACHO-ARM-NEXT: ]