[objdump] Support finding --source via --dsym files

Add support for auto-detecting or specifying dSYM files/directories to
allow interleaving source with disassembly.

Differential Revision: https:/

[objdump] Support finding --source via --dsym files

Add support for auto-detecting or specifying dSYM files/directories to
allow interleaving source with disassembly.

Differential Revision: https://reviews.llvm.org/D135117

Patch by Jim Radford.

show more ...

[llvm-objdump] --no-leading-addr: hide inline relocation offsets

It seems to make sense to omit offsets when --no-leading-addr is specified. The output is now closer
to objdump -dr --no-addresses (n

[llvm-objdump] --no-leading-addr: hide inline relocation offsets

It seems to make sense to omit offsets when --no-leading-addr is specified. The output is now closer
to objdump -dr --no-addresses (non-wide output).

Reviewed By: nickdesaulniers

Differential Revision: https://reviews.llvm.org/D135039

show more ...

[llvm-objdump] Find debug information with Build ID/debuginfod.

Uses the library introduced in https://reviews.llvm.org/D132504 to add build ID fetching to llvm-objdump. This allows viewing source w

[llvm-objdump] Find debug information with Build ID/debuginfod.

Uses the library introduced in https://reviews.llvm.org/D132504 to add build ID fetching to llvm-objdump. This allows viewing source when disassembling stripped objects.

Reviewed By: jhenderson

Differential Revision: https://reviews.llvm.org/D131224

show more ...

[llvm-objdump] Create name for fake sections

It doesn't have a section header string table so add a vector to have
the strings and create name based on the program header type and the
index.

Differ

[llvm-objdump] Create name for fake sections

It doesn't have a section header string table so add a vector to have
the strings and create name based on the program header type and the
index.

Differential Revision: https://reviews.llvm.org/D131290

show more ...

[llvm-objdump] Handle multiple syms at same addr in disassembly.

The main disassembly loop in llvm-objdump works by iterating through
the symbols in a code section, and for each one, dumping the ran

[llvm-objdump] Handle multiple syms at same addr in disassembly.

The main disassembly loop in llvm-objdump works by iterating through
the symbols in a code section, and for each one, dumping the range of
the section from that symbol to the next. If there's another symbol
defined at the same location, then that range will have length 0, and
llvm-objdump will skip over the symbol entirely.

As a result, llvm-objdump will only show the last of the symbols
defined at that address. Not only that, but the other symbols won't
even be checked against the `--disassemble-symbol` list. So if you
have two symbols `foo` and `bar` defined in the same place, then one
of `--disassemble-symbol=foo` and `--disassemble-symbol=bar` will
generate an error message and no disassembly.

I think a better approach in that situation is to prioritise display
of the symbol the user actually asked for. Also, if the user
specifically asks for disassembly of //both// of two symbols defined
at the same address, the best response I can think of is to
disassemble the code once, preceded by both symbol names.

This involves teaching llvm-objdump to be able to display more than
one symbol name at the head of a disassembled section, which also
makes it possible to implement a `--show-all-symbols` option to
display //every// symbol defined in the code, not just the most
preferred one at each address.

This change also turns out to fix a bug in which `--disassemble-all`
on a mixed Arm/Thumb ELF file would fail to switch disassembly states
between Arm and Thumb functions, because the mapping symbols were
accidentally ignored.

Reviewed By: jhenderson

Differential Revision: https://reviews.llvm.org/D131589

show more ...

Remove redundant initialization of Optional (NFC)

[llvm-objdump --macho] Rename --dyld_info to --dyld-info

llvm-objdump takes foo-bar style flags, while llvm-otool takes foo_bar style
flags. dyld_info was the only exception to that.

Add a -dyld_i

[llvm-objdump --macho] Rename --dyld_info to --dyld-info

llvm-objdump takes foo-bar style flags, while llvm-otool takes foo_bar style
flags. dyld_info was the only exception to that.

Add a -dyld_info flag to llvm-otool instead.

(Both in llvm-objdump and llvm-otool, the flag doesn't really do anything
yet.)

Differential Revision: https://reviews.llvm.org/D131897

show more ...

[llvm-objdump] Start on -chained_fixups for llvm-otool

And --chained-fixups for llvm-objdump.

For now, this only prints the dyld_chained_fixups_header and adds
plumbing for the flag. This will be e

[llvm-objdump] Start on -chained_fixups for llvm-otool

And --chained-fixups for llvm-objdump.

For now, this only prints the dyld_chained_fixups_header and adds
plumbing for the flag. This will be expanded in future commits.

When Apple's effort to upstream their chained fixups code continues,
we'll replace this code with the then-upstreamed code. But we need
something in the meantime for testing ld64.lld's chained fixups
code.

Update chained-fixups.yaml with a file that actually contains
the chained fixup data (`LinkEditData` doesn't encode it yet,
so use `__LINKEDIT` via `--raw-segment=data`).

Differential Revision: https://reviews.llvm.org/D131890

show more ...

[llvm-objdump,ARM] Fix big-endian AArch32 disassembly.

The ABI for big-endian AArch32, as specified by AAELF32, is above-
averagely complicated. Relocatable object files are expected to store
instru

[llvm-objdump,ARM] Fix big-endian AArch32 disassembly.

The ABI for big-endian AArch32, as specified by AAELF32, is above-
averagely complicated. Relocatable object files are expected to store
instruction encodings in byte order matching the ELF file's endianness
(so, big-endian for a BE ELF file). But executable images can
//either// do that //or// store instructions little-endian regardless
of data and ELF endianness (to support BE32 and BE8 platforms
respectively). They signal the latter by setting the EF_ARM_BE8 flag
in the ELF header.

(In the case of the Thumb instruction set, this all means that each
16-bit halfword of a Thumb instruction is stored in one or other
endianness. The two halfwords of a 32-bit Thumb instruction must
appear in the same order no matter what, because the first halfword is
the one that must avoid overlapping the encoding of any 16-bit Thumb
instruction.)

llvm-objdump was unconditionally expecting Arm instructions to be
stored little-endian. So it would correctly disassemble a BE8 image,
but if you gave it a BE32 image or a BE object file, it would retrieve
every instruction in byte-swapped form and disassemble it to
nonsense. (Even an object file output by LLVM itself, because
ARMMCCodeEmitter outputs instructions big-endian in big-endian mode,
which is correct for writing an object file.)

This patch allows llvm-objdump to correctly disassemble all three of
those classes of Arm ELF file. It does it by introducing a new
SubtargetFeature for big-endian instructions, setting it from the ELF
image type and flags during llvm-objdump setup, and teaching both
ARMDisassembler and llvm-objdump itself to pay attention to it when
retrieving instruction data from a section being disassembled.

Differential Revision: https://reviews.llvm.org/D130902

show more ...

[llvm-objdump] Fix type mismatch in std::min.

I broke the build just now by trying to do std::min between a size_t
and a uint64_t, which of course worked fine on my 64-bit test platform.

[llvm-objdump,ARM] Make dumpARMELFData line up with instructions.

The whitespace in output lines containing disassembled instructions
was extremely mismatched against that in `.word` lines produced

[llvm-objdump,ARM] Make dumpARMELFData line up with instructions.

The whitespace in output lines containing disassembled instructions
was extremely mismatched against that in `.word` lines produced from
dumping literal pools and other data in Arm ELF files. This patch
adjusts `dumpARMELFData` so that it uses the same alignment system as
in the instruction pretty-printers. Now the two classes of line are
aligned sensibly alongside each other.

Reviewed By: DavidSpickett

Differential Revision: https://reviews.llvm.org/D130359

show more ...

[llvm-objdump,ARM] Add PrettyPrinters for Arm and AArch64.

Most Arm disassemblers, including GNU objdump and Arm's own `fromelf`,
emit an instruction's raw encoding as a 32-bit words or (for Thumb)

[llvm-objdump,ARM] Add PrettyPrinters for Arm and AArch64.

Most Arm disassemblers, including GNU objdump and Arm's own `fromelf`,
emit an instruction's raw encoding as a 32-bit words or (for Thumb)
one or two 16-bit halfwords, in logical order rather than according to
their storage endianness. This is generally easier to read: it matches
the encoding diagrams in the architecture spec, it matches the value
you'd write in a `.inst` directive, and it means that fields within
the instruction encoding that span more than one byte (such as branch
offsets or `SVC` immediates) can be read directly in the encoding
without having to mentally reverse the bytes.

llvm-objdump already has a system of PrettyPrinter subclasses which
makes it easy for a target to drop in its own preferred formatting.
This patch adds pretty-printers for all the Arm targets, so that
llvm-objdump will display Arm instruction encodings in their preferred
layout instead of little-endian and bytewise.

Reviewed By: DavidSpickett

Differential Revision: https://reviews.llvm.org/D130358

show more ...

[MC,llvm-objdump,ARM] Target-dependent disassembly resync policy.

Currently, when llvm-objdump is disassembling a code section and
encounters a point where no instruction can be decoded, it uses the

[MC,llvm-objdump,ARM] Target-dependent disassembly resync policy.

Currently, when llvm-objdump is disassembling a code section and
encounters a point where no instruction can be decoded, it uses the
same policy on all targets: consume one byte of the section, emit it
as "<unknown>", and try disassembling from the next byte position.

On an architecture where instructions are always 4 bytes long and
4-byte aligned, this makes no sense at all. If a 4-byte word cannot be
decoded as an instruction, then the next place that a valid
instruction could //possibly// be found is 4 bytes further on.
Disassembling from a misaligned address can't possibly produce
anything that the code generator intended, or that the CPU would even
attempt to execute.

This patch introduces a new MCDisassembler virtual method called
`suggestBytesToSkip`, which allows each target to choose its own
resynchronization policy. For Arm (as opposed to Thumb) and AArch64,
I've filled in the new method to return a fixed width of 4.

Thumb is a more interesting case, because the criterion for
identifying 2-byte and 4-byte instruction encodings is very simple,
and doesn't require the particular instruction to be recognized. So
`suggestBytesToSkip` is also passed an ArrayRef of the bytes in
question, so that it can take that into account. The new test case
shows Thumb disassembly skipping over two unrecognized instructions,
and identifying one as 2-byte and one as 4-byte.

For targets other than Arm and AArch64, this is NFC: the base class
implementation of `suggestBytesToSkip` still returns 1, so that the
existing behavior is unchanged. Other targets can fill in their own
implementations as they see fit; I haven't attempted to choose a new
behavior for each one myself.

I've updated all the call sites of `MCDisassembler::getInstruction` in
llvm-objdump, and also one in sancov, which was the only other place I
spotted the same idiom of `if (Size == 0) Size = 1` after a call to
`getInstruction`.

Reviewed By: DavidSpickett

Differential Revision: https://reviews.llvm.org/D130357

show more ...

[llvm-objdump,ARM] Fix .byte directives dumping the wrong byte.

The clause in `dumpARMELFData` that dumps a single byte as a `.byte`
directive was printing the operand of that directive as `Bytes[0]

[llvm-objdump,ARM] Fix .byte directives dumping the wrong byte.

The clause in `dumpARMELFData` that dumps a single byte as a `.byte`
directive was printing the operand of that directive as `Bytes[0]`,
not `Bytes[Index]`. In particular, this led to the `dumpBytes` output
to its left not matching it!

Reviewed By: DavidSpickett

Differential Revision: https://reviews.llvm.org/D130360

show more ...

[llvm-objdump] Support --symbolize-operands when there is a single SHT_LLVM_BB_ADDR_MAP section for all text sections

When linking, using `-Wl,-z,keep-text-section-prefix` results in multiple text s

[llvm-objdump] Support --symbolize-operands when there is a single SHT_LLVM_BB_ADDR_MAP section for all text sections

When linking, using `-Wl,-z,keep-text-section-prefix` results in multiple text sections while all `SHT_LLVM_BB_ADDR_MAP` sections are linked into a single one.
In such case, we should not read the corresponding section for each text section, and instead read all `SHT_LLVM_BB_ADDR_MAP` sections before disassembly.

Reviewed By: jhenderson, MaskRay

Differential Revision: https://reviews.llvm.org/D129924

show more ...

[llvm-objdump] Create fake sections for a ELF core file

The linux perf tools use /proc/kcore for disassembly kernel functions.
Actually it copies the relevant parts to a temp file and then pass it t

[llvm-objdump] Create fake sections for a ELF core file

The linux perf tools use /proc/kcore for disassembly kernel functions.
Actually it copies the relevant parts to a temp file and then pass it to
objdump. But it doesn't have section headers so llvm-objdump cannot
handle it.

Let's create fake section headers for the program headers. It'd have a
single section for each segment to cover the entire range. And for this
purpose we can consider only executable code segments.

With this change, I can see the following command shows proper outputs.

perf annotate --stdio --objdump=/path/to/llvm-objdump

Differential Revision: https://reviews.llvm.org/D128705

show more ...

[llvm] Use value instead of getValue (NFC)

[llvm-objdump] Change some nonnull pointers to references. NFC

[llvm-objdump] Add support for dumping embedded offloading data

In Clang/LLVM we are moving towards a new binary format to store many
embedded object files to create a fatbinary. This patch adds sup

[llvm-objdump] Add support for dumping embedded offloading data

In Clang/LLVM we are moving towards a new binary format to store many
embedded object files to create a fatbinary. This patch adds support for
dumping these embedded images in the `llvm-objdump` tool. This will
allow users to query information about what is stored inside the binary.
This has very similar functionality to the `cuobjdump` tool for thoe familiar
with the Nvidia utilities. The proposed use is as follows:
```
$ clang input.c -fopenmp --offload-arch=sm_70 --offload-arch=sm_52 -c
$ llvm-objdump -O input.o

input.o: file format elf64-x86-64

OFFLOADIND IMAGE [0]:
kind cubin
arch sm_52
triple nvptx64-nvidia-cuda
producer openmp

OFFLOADIND IMAGE [1]:
kind cubin
arch sm_70
triple nvptx64-nvidia-cuda
producer openmp
```

This will be expanded further once we start embedding more information
into these offloading images. Right now we are planning on adding
flags and entries for debug level, optimization, LTO usage, target
features, among others.

This patch only supports printing these sections, later we will want to
support dumping files the user may be interested in via another flag. I
am unsure if this should go here in `llvm-objdump` or `llvm-objcopy`.

Reviewed By: MaskRay, tra, jhenderson, JonChesterfield

Differential Revision: https://reviews.llvm.org/D126904

show more ...

[llvm-objdump] -r: print non-SHF_ALLOC relocations for non-ET_REL files

ET_EXEC and ET_DYN files may contain non-SHF_ALLOC relocation sections
(e.g. ld --emit-relocs). Match GNU objdump by dumping t

[llvm-objdump] -r: print non-SHF_ALLOC relocations for non-ET_REL files

ET_EXEC and ET_DYN files may contain non-SHF_ALLOC relocation sections
(e.g. ld --emit-relocs). Match GNU objdump by dumping them.

* Remove Object/dynamic-reloc.test. Replace it with a -r RUN line in dynamic-relocs.test
* Update relocations-in-nonreloc.test to set sh_link/sh_info. GNU
objdump seems to ignore a SHT_REL/SHT_RELA section not linking to SHT_SYMTAB.
The test did not test what it intended to test.

Fix https://github.com/llvm/llvm-project/issues/41246

Reviewed By: jhenderson

Differential Revision: https://reviews.llvm.org/D128959

show more ...

[llvm-objdump] Default to --mattr=+all for AArch64

GNU objdump disassembles all unknown instructions by default. Match this user
friendly behavior with the target feature "all" (D128029) designed fo

[llvm-objdump] Default to --mattr=+all for AArch64

GNU objdump disassembles all unknown instructions by default. Match this user
friendly behavior with the target feature "all" (D128029) designed for disassemblers.

Reviewed By: jhenderson

Differential Revision: https://reviews.llvm.org/D128030

show more ...

[llvm] Don't use Optional::hasValue (NFC)

This patch replaces Optional::hasValue with the implicit cast to bool
in conditionals only.

Revert "Don't use Optional::hasValue (NFC)"

This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.

Don't use Optional::hasValue (NFC)

[llvm] Don't use Optional::getValue (NFC)