[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)

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

[llvm] Use value_or instead of getValueOr (NFC)

[llvm-objdump] Let --symbolize-operands symbolize basic block addresses based on the SHT_LLVM_BB_ADDR_MAP section.

`--symbolize-operands` already symbolizes branch targets based on the disassembly.

[llvm-objdump] Let --symbolize-operands symbolize basic block addresses based on the SHT_LLVM_BB_ADDR_MAP section.

`--symbolize-operands` already symbolizes branch targets based on the disassembly. When the object file is created with `-fbasic-block-sections=labels` (ELF-only) it will include a SHT_LLVM_BB_ADDR_MAP section which maps basic blocks to their addresses. In such case `llvm-objdump` can annotate the disassembly based on labels inferred on this section.

In contrast to the current labels, SHT_LLVM_BB_ADDR_MAP-based labels are created for every machine basic block including empty blocks and those which are not branched into (fallthrough blocks).

The old logic is still executed even when the SHT_LLVM_BB_ADDR_MAP section is present to handle functions which have not been received an entry in this section.

Reviewed By: jhenderson, MaskRay

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

show more ...

[CSKY] Enhance asm parser and relocation fixup for some special symbol address instruction

Add processing of parsing and emiting lrw/jsri/jmpi instruction, including related fixup and relocation.
Ad

[CSKY] Enhance asm parser and relocation fixup for some special symbol address instruction

Add processing of parsing and emiting lrw/jsri/jmpi instruction, including related fixup and relocation.
Add relax support about pseudo instructions such as jbr/jbsr.
Add objdump format support like arm in llvm-objdump.

show more ...

Cleanup include: DebugInfo/Symbolize

Estimation of the impact on preprocessor output
after: 1067349756
before:1067487786

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-

Cleanup include: DebugInfo/Symbolize

Estimation of the impact on preprocessor output
after: 1067349756
before:1067487786

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D120433

show more ...

Add a (nonfunctional) -dyld_info flag to llvm-objdump.

Darwin otool implements this flag as a one-stop solution for
displaying bind and rebase info. As I am working on upstreaming
chained fixup supp

Add a (nonfunctional) -dyld_info flag to llvm-objdump.

Darwin otool implements this flag as a one-stop solution for
displaying bind and rebase info. As I am working on upstreaming
chained fixup support this command will be useful to write testcases.

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

show more ...

Reland [XCOFF][llvm-objdump] change the priority of symbols with the same address by symbol types.

Fix the Buildbot failure #19373.

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

Revert "[XCOFF][llvm-objdump] change the priority of symbols with"

This reverts commit 2ad662172cbbd1ca53489bf8bddb0183d7692708.

Buildbot failure #19373

[XCOFF][llvm-objdump] change the priority of symbols with
the same address by symbol types.

Summary: In XCOFF, each section comes with a default symbol
with the same n

[XCOFF][llvm-objdump] change the priority of symbols with
the same address by symbol types.

Summary: In XCOFF, each section comes with a default symbol
with the same name as the section. It doesn't bind
to code locations and it may cause incorrect display
of symbol names under `llvm-objdump -d`.
This patch changes the priority of symbols with the
same address by symbol type.

Reviewed By: jhenderson, shchenz

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

show more ...