This implements an LLVM tool that's flag- and output-compatible with macOS's `otool` -- except for bugs, but from testing with both `otool` and `xcrun otool-classic`, llvm-otool matches vanilla otool's behavior very well already. It's not 100% perfect, but it's a very solid start. This uses the same approach as llvm-objcopy: llvm-objdump uses a different OptTable when it's invoked as llvm-otool. This is possible thanks to D100433. Differential Revision: https://reviews.llvm.org/D100583
19 lines
816 B
Plaintext
19 lines
816 B
Plaintext
RUN: llvm-objdump -m --data-in-code %p/Inputs/data-in-code.macho-arm | FileCheck %s
|
|
RUN: llvm-otool -Gv %p/Inputs/data-in-code.macho-arm | FileCheck %s
|
|
RUN: llvm-objdump -m --data-in-code --non-verbose %p/Inputs/data-in-code.macho-arm | FileCheck %s --check-prefix=NON_VERBOSE
|
|
RUN: llvm-otool -G %p/Inputs/data-in-code.macho-arm | FileCheck %s --check-prefix=NON_VERBOSE
|
|
|
|
CHECK: Data in code table (4 entries)
|
|
CHECK: offset length kind
|
|
CHECK: 0x00000000 4 DATA
|
|
CHECK: 0x00000004 4 JUMP_TABLE32
|
|
CHECK: 0x00000008 2 JUMP_TABLE16
|
|
CHECK: 0x0000000a 1 JUMP_TABLE8
|
|
|
|
NON_VERBOSE: Data in code table (4 entries)
|
|
NON_VERBOSE: offset length kind
|
|
NON_VERBOSE: 0x00000000 4 0x0001
|
|
NON_VERBOSE: 0x00000004 4 0x0004
|
|
NON_VERBOSE: 0x00000008 2 0x0003
|
|
NON_VERBOSE: 0x0000000a 1 0x0002
|