This presents misleading and confusing output. If you have a function
defined at the beginning of an XCOFF object file, and you have a
function call to an external function, the function call disassembles as
a branch to the local function. That is,
`void f() { f(); g();}`
disassembles as
>00000000 <.f>:
0: 7c 08 02 a6 mflr 0
4: 94 21 ff c0 stwu 1, -64(1)
8: 90 01 00 48 stw 0, 72(1)
c: 4b ff ff f5 bl 0x0 <.f>
10: 4b ff ff f1 bl 0x0 <.f>
With this PR, the second call will display:
`10: 4b ff ff f1 bl 0x0 <.g> `
Using -r can help, but you still get the confusing output:
>10: 4b ff ff f1 bl 0x0 <.f>
00000010: R_RBR .g
The current (experimental) spec for WebAssembly shared libraries does
not include a full symbol table like the object format. This change
extracts symbol information from the normal wasm exports.
This is the first step in having the linker report undefined symbols
when linking with shared libraries. The current behaviour is to ignore
all undefined symbols when linking with `-pie` or `-shared`.
See https://github.com/emscripten-core/emscripten/issues/18198
When llvm-objdump switched from cl:: to OptTable
(https://reviews.llvm.org/D100433), we dropped support for LLVM cl::
options. Some LLVM_DEBUG in `llvm/lib/Target/$target/MCDisassembler/`
files might be useful. Add -mllvm to allow dumping the information.
```
# -debug is available in an LLVM_ENABLE_ASSERTIONS=on build
llvm-objdump -d -mllvm -debug a.o > /dev/null
```
Link:
https://discourse.llvm.org/t/how-to-enable-debug-logs-in-llvm-objdump/75758
When a section contains two functions x1 and x2, we incorrectly display
x1's relocations when dumping x2 for `--disassemble-symbols=x2 -r`.
Fix#75539 by ignoring these relocations.
Branch-absolute instructions are currently printed in decimal, and
negative addresses are printed as positive numbers.
With this change, addresses are printed in hex and negative addresses
are converted to an unsigned 32- or 64-bit address.
This patch introduces llvm-objdump tests for new `AARCH64_AUTH_RELR`,
`AARCH64_AUTH_RELRSZ` and `AARCH64_AUTH_RELRENT` dynamic tags.
Depends on https://github.com/llvm/llvm-project/pull/74874
llvm-readobj and llvm-objdump have inconsistent handling of display
lma for sections.
This patch tries to common code up and adapt the same approach for
both tools.
Function evaluateBranch() is used to compute target address for a given
branch instruction and return true on success. But target address of
indirect branch cannot be simply added, so rule it out and just return
false.
This patch also add objdump tests which capture the current state of
support for printing branch targets. Without this patch, the result of
"jirl $zero, $a0, 4" is "jirl $zero, $a0, 4 <foo+0x64>". It is obviously
incorrect, because this instruction represents an indirect branch whose
target address depends on both the register value and the imm. After
this patch, it will be right despite loss of details.
This patch implements `MCInstrAnalysis` state in order to be able
analyze auipc+jalr pairs inside `evaluateBranch`.
This is implemented as follows:
- State: array of currently known GPR values;
- Whenever an auipc is detected in `updateState`, update the state value
of RD with the immediate;
- Whenever a jalr is detected in `evaluateBranch`, check if the state
holds a value for RS1 and use that to compute its target.
Note that this is similar to how binutils implements it and the output
of llvm-objdump should now mostly match the one of GNU objdump.
This patch also updates the relevant llvm-objdump patches and adds a new
one testing the output for interleaved auipc+jalr pairs.
- Be explicit about which program resource register is supported by
which target
- RSRC1
- FP16_OVFL is GFX9+
- WGP_MODE is GFX10+
- MEM_ORDERED is GFX10+
- FWD_PROGRESS is GFX10+
- RSRC3
- INST_PREF_SIZE is GFX11+
- TRAP_ON_START is GFX11+
- TRAP_ON_END is GFX11+
- IMAGE_OP is GFX11+
- Do not emit GFX11+ fields when disassembling GFX10 code objects
- Tighten enforcement of reserved bits in disassembler
---------
Co-authored-by: Konstantin Zhuravlyov <kzhuravl@amd.com>
Extend llvm-objdump to show CO-RE relocations when `-r` option is
passed and object file has .BTF and .BTF.ext sections.
For example, the following C program:
#define __pai __attribute__((preserve_access_index))
struct foo { int i; int j;} __pai;
struct bar { struct foo f[7]; } __pai;
extern void sink(void *);
void root(struct bar *bar) {
sink(&bar[2].f[3].j);
}
Should lead to the following objdump output:
$ clang --target=bpf -O2 -g t.c -c -o - | \
llvm-objdump --no-addresses --no-show-raw-insn -dr -
...
r2 = 0x94
CO-RE <byte_off> [2] struct bar::[2].f[3].j (2:0:3:1)
r1 += r2
call -0x1
R_BPF_64_32 sink
exit
...
More examples could be found in unit tests, see BTFParserTest.cpp.
To achieve this:
- Move CO-RE relocation kinds definitions from BPFCORE.h to BTF.h.
- Extend BTF.h with types derived from BTF::CommonType, e.g.
BTF::IntType and BTF::StrutType, to allow dyn_cast() and access to
type additional data.
- Extend BTFParser to load BTF type and relocation data.
- Modify llvm-objdump.cpp to create instance of BTFParser when
disassembly of object file with BTF sections is processed and `-r`
flag is supplied.
Additional information about CO-RE is available at [1].
[1] https://docs.kernel.org/bpf/llvm_reloc.html
Depends on D149058
Differential Revision: https://reviews.llvm.org/D150079
Add assembler directives for preloading kernel arguments that correspond
to new fields in the kernel descriptor for the length and offset of
arguments that will be placed in SGPRs prior to kernel launch. Alignment
of the arguments in SGPRs is equivalent to the kernarg segment when
accessed via the kernarg_segment_ptr. Kernarg SGPRs are allocated
directly after other user SGPRs.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D159459
If a virtual register is not assigned preferred physical register, it means some
COPY instructions will be changed to real register move instructions. In this
case we can try to split the virtual register in colder blocks, if success, the
original COPY instructions can be deleted, and the new COPY instructions in
colder blocks will be generated as register move instructions. It results in
fewer dynamic register move instructions executed.
The new test case split-reg-with-hint.ll gives an example, the hot path contains
24 instructions without this patch, now it is only 4 instructions with this
patch.
Differential Revision: https://reviews.llvm.org/D156491
Add a shouldAdjustVA(Section) guard on top of address update.
Update llvm-objdump file to update symbol table when --adjust-vma used.
Fixes#63203
Patch by HamidrezaSK (Hamidreza Sanaee)
Enable color highlighting of disassembly in llvm-objdump. This patch
introduces a new flag --disassembler-color=<mode> that enables or
disables highlighting disassembly with ANSI escape codes. The default
mode is to enable color highlighting if outputting to a color-enabled
terminal.
Differential revision: https://reviews.llvm.org/D159224
When 7a28b0b60e added this it wanted
"llvm-objdump: warning: <...>". On our Windows on Arm bot you get:
c:\users\tcwg\llvm-worker\clang-arm64-windows-msvc\stage1\bin\llvm-objdump.exe: warning:
Seems unlikely the warning would come from anywhere else and if
it does, this test isn't the one to be catching that. So I've
shortened the checks to start at "warning: ".
Many sources show that xxh3 is much better than xxh64. This particular
instance may or may not have noticeable difference, but this change
moves us toward removing xxHash64.
This change will invalid cache.
Reviewed By: mysterymath
Differential Revision: https://reviews.llvm.org/D155993
The current implementation generates a csect with a
".rodata.str.x.y" prefix for a MergeableCString variable definition.
However, a reference to such variable does not get the prefix in its
name because there's not enough information in the containing IR.
In particular, without seeing the initializer and absent of some other
indicators, we cannot tell that the referenced variable is a null-
terminated string.
When the AIX codegen in llvm was being developed, the prefixing was copied
from ELF without having the linker take advantage of the info.
Currently, the AIX linker does not have the capability to merge
MergeableCString variables. If such feature would ever get implemented,
the contract between the linker and compiler would have to be reconsidered.
Here's the before and after of this change:
```
@a = global i64 320255973571806, align 8
@strA = unnamed_addr constant [7 x i8] c"hello\0A\00", align 1 ;; Mergeable1ByteCString
@strB = unnamed_addr constant [8 x i8] c"Blahah\0A\00", align 1 ;; Mergeable1ByteCString
@strC = unnamed_addr constant [2 x i16] [i16 1, i16 0], align 2 ;; Mergeable2ByteCString
@strD = unnamed_addr constant [2 x i16] [i16 1, i16 1], align 2 ;; !isMergeableCString
@strE = external unnamed_addr constant [2 x i16], align 2
-fdata-sections:
.text extern .rodata.str1.1strA .text extern strA
0 SD RO 0 SD RO
.text extern .rodata.str1.1strB .text extern strB
0 SD RO 0 SD RO
.text extern .rodata.str2.2strC ===> .text extern strC
0 SD RO 0 SD RO
.text extern strD .text extern strD
0 SD RO 0 SD RO
.data extern a .data extern a
0 SD RW 0 SD RW
undef extern strE undef extern strE
0 ER UA 0 ER UA
-fno-data-sections:
.text unamex .rodata.str1.1 .text unamex .rodata
0 SD RO 0 SD RO
.text extern strA .text extern strA
0 LD RO 0 LD RO
.text extern strB .text extern strB
0 LD RO 0 LD RO
.text unamex .rodata.str2.2 ===> .text extern strC
0 SD RO 0 LD RO
.text extern strC .text extern strD
0 LD RO 0 LD RO
.text unamex .rodata .data unamex .data
0 SD RO 0 SD RW
.text extern strD .data extern a
0 LD RO 0 LD RW
.data unamex .data undef extern strE
0 SD RW 0 ER UA
.data extern a
0 LD RW
undef extern strE
0 ER UA
```
Reviewed by: David Tenty, Fangrui Song
Differential Revision: https://reviews.llvm.org/D156202
Similar to D96617 for llvm-symbolizer.
This patch matches the GNU objdump -d behavior to suppress printing
labels for mapping symbols. Mapping symbol names don't convey much
information.
When --show-all-symbols (not in GNU) is specified, we still print
mapping symbols.
Note: the `for (size_t SI = 0, SE = Symbols.size(); SI != SE;)` loops
needs to iterate all mapping symbols, even if they are not displayed.
We use the new field `IsMappingSymbol` to recognize mapping symbols.
This field also enables simplification after D139131.
ELF/ARM/disassemble-all-mapping-symbols.s is enhanced to add `.space 2`.
If `End = std::min(End, Symbols[SI].Addr);` is not correctly set, we
would print a `.word`.
Reviewed By: jhenderson, jobnoorman, peter.smith
Differential Revision: https://reviews.llvm.org/D156190
ARM64EC/ARM64X binaries use ARM64 or AMD64 machine types, but provide
additional CHPE metadata that may be used to distinguish them from
pure ARM64/AMD64 binaries.
Reviewed By: jhenderson, MaskRay, mstorsjo
Differential Revision: https://reviews.llvm.org/D149091
When generating XCOFF, the compiler generates a csect with an internal
name. Each function results in a label within the csect. This patch
replaces the internal name ".text" with an empty string "". This avoids
adding special code to handle a function text() in the source file, and
works better with some XCOFF tools that are confused when the csect and
the first function have the same address.
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D154854
Extend D127824 to the 32-bit Power architecture.
AFAICT GNU objdump -d dumps all instructions for 32-bit as well.
Reviewed By: #powerpc, nemanjai
Differential Revision: https://reviews.llvm.org/D155114
"BTF" is a debug information format used by LLVM's BPF backend.
The format is much smaller in scope than DWARF, the following info is
available:
- full set of C types used in the binary file;
- types for global values;
- line number / line source code information .
BTF information is embedded in ELF as .BTF and .BTF.ext sections.
Detailed format description could be found as a part of Linux Source
tree, e.g. here: [1].
This commit modifies `llvm-objdump` utility to use line number
information provided by BTF if DWARF information is not available.
E.g., the goal is to make the following to print source code lines,
interleaved with disassembly:
$ clang --target=bpf -g test.c -o test.o
$ llvm-strip --strip-debug test.o
$ llvm-objdump -Sd test.o
test.o: file format elf64-bpf
Disassembly of section .text:
<foo>:
; void foo(void) {
r1 = 0x1
; consume(1);
call -0x1
r1 = 0x2
; consume(2);
call -0x1
; }
exit
A common production use case for BPF programs is to:
- compile separate object files using clang with `-g -c` flags;
- link these files as a final "static" binary using bpftool linker ([2]).
The bpftool linker discards most of the DWARF sections
(line information sections as well) but merges .BTF and .BTF.ext sections.
Hence, having `llvm-objdump` capable to print source code using .BTF.ext
is valuable.
The commit consists of the following modifications:
- llvm/lib/DebugInfo/BTF aka `DebugInfoBTF` component is added to host
the code needed to process BTF (with assumption that BTF support
would be added to some other tools as well, e.g. `llvm-readelf`):
- `DebugInfoBTF` provides `llvm::BTFParser` class, that loads information
from `.BTF` and `.BTF.ext` sections of a given `object::ObjectFile`
instance and allows to query this information.
Currently only line number information is loaded.
- `DebugInfoBTF` also provides `llvm::BTFContext` class, which is an
implementation of `DIContext` interface, used by `llvm-objdump` to
query information about line numbers corresponding to specific
instructions.
- Structure `DILineInfo` is modified with field `LineSource`.
`DIContext` interface uses `DILineInfo` structure to communicate
line number and source code information.
Specifically, `DILineInfo::Source` field encodes full file source code,
if available. BTF only stores source code for selected lines of the
file, not a complete source file. Moreover, stored lines are not
guaranteed to be sorted in a specific order.
To avoid reconstruction of a file source code from a set of
available lines, this commit adds `LineSource` field instead.
- `Symbolize` class is modified to use `BTFContext` instead of
`DWARFContext` when DWARF sections are not available but BTF
sections are present in the object file.
(`Symbolize` is instantiated by `llvm-objdump`).
- Integration and unit tests.
Note, that DWARF has a notion of "instruction sequence".
DWARF implementation of `DIContext::getLineInfoForAddress()` provides
inexact responses if exact address information is not available but
address falls within "instruction sequence" with some known line
information (see `DWARFDebugLine::LineTable::findRowInSeq()`).
BTF does not provide instruction sequence groupings, thus
`getLineInfoForAddress()` queries only return exact matches.
This does not seem to be a big issue in practice, but output
of the `llvm-objdump -Sd` might differ slightly when BTF
is used instead of DWARF.
[1] https://www.kernel.org/doc/html/latest/bpf/btf.html
[2] https://github.com/libbpf/bpftool
Depends on https://reviews.llvm.org/D149501
Reviewed By: MaskRay, yonghong-song, nickdesaulniers, #debug-info
Differential Revision: https://reviews.llvm.org/D149058
Found a bug in ElfObjectFile.h that occurred when there was an invalid Symbol Name in an object file. This error affected the behavior of the Expected<> value and leading it to abort, rather than behave as normal. I found this as I was adding tests to llvm-cm, as prompted by @jhenderson.
Without this fix, upon encountering an invalid symbol and trying tot l get its name, the program states that
```Expected<T> must be checked before access or destruction```
and aborts.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D154665
Port D69671 (llvm-readobj) to llvm-objdump. Add a class llvm::objdump::Dumper
and move some free functions into Dumper so that they can call
reportUniqueWarning.
Warnings seems preferable in these cases as the issue is localized and we can
continue dumping other information.
Differential Revision: https://reviews.llvm.org/D154754
* Relax the AsmParser to accept `.amdhsa_wavefront_size32 0` when the
`.amdhsa_shared_vgpr_count` directive is present.
* Teach the KD disassembler to respect the setting of
KERNEL_CODE_PROPERTY_ENABLE_WAVEFRONT_SIZE32 when calculating the
value of `.amdhsa_next_free_vgpr`.
* Teach the KD disassembler to disassemble COMPUTE_PGM_RSRC3 for gfx90a
and gfx10+.
* Include "pseudo directive" comments for gfx10 fields which are not
controlled by any assembler directive.
* Fix disassembleObject failure diagnostic in llvm-objdump to not
hard-code a comment string, and to follow the convention of not
capitalizing the first sentence.
Reviewed By: rochauha
Differential Revision: https://reviews.llvm.org/D128014
Summary:
Adding a new option -traceback-table to print out the traceback info of xcoff ojbect file.
Reviewers: James Henderson, Fangrui Song, Stephen Peckham, Xing Xue
Differential Revision: https://reviews.llvm.org/D89049
Clean up ahead of a patch to fix bugs in the AMDGPUDisassembler.
Use split-file to simplify and extend existing kernel-descriptor
disassembly tests.
Add a comment to AMDHSAKernelDescriptor.h, as at least one small set
towards keeping all kernel-descriptor sensitive code in sync.
Reviewed By: MaskRay, kzhuravl, arsenm
Differential Revision: https://reviews.llvm.org/D130105
They will demonstrate some symbol that --adjust-vma= should not adjust.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D153401
This is a follow-up to b71edfaa4e
since I forgot the lit.local.cfg files in that one.
Reformatting is done with `black`.
If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.
If you run into any problems, post to discourse about it and
we will try to help.
RFC Thread below:
https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Reviewed By: barannikov88, kwk
Differential Revision: https://reviews.llvm.org/D150762
If a symbol needs both JUMP_SLOT and GLOB_DAT relocations, there is a
minor linker optimization to keep just GLOB_DAT. This optimization
is only implemented by GNU ld's x86 port and mold.
https://maskray.me/blog/2021-08-29-all-about-global-offset-table#combining-.got-and-.got.plt
With the optimizing, the PLT entry is placed in .plt.got and the
associated GOTPLT entry is placed in .got (ld.bfd -z now) or .got.plt (ld.bfd -z lazy).
The relocation is in .rel[a].dyn.
This patch synthesizes `symbol@plt` labels for these .plt.got entries.
Example:
```
cat > a.s <<e
.globl _start; _start:
mov combined0@gotpcrel(%rip), %rax; mov combined1@gotpcrel(%rip), %rax
call combined0@plt; call combined1@plt
call foo0@plt; call foo1@plt
e
cat > b.s <<e
.globl foo0, foo1, combined0, combined1
foo0: foo1: combined0: combined1:
e
gcc -fuse-ld=bfd -shared b.s -o b.so
gcc -fuse-ld=bfd -pie -nostdlib a.s b.so -o a
```
```
Disassembly of section .plt:
0000000000001000 <.plt>:
1000: ff 35 ea 1f 00 00 pushq 0x1fea(%rip) # 0x2ff0 <_GLOBAL_OFFSET_TABLE_+0x8>
1006: ff 25 ec 1f 00 00 jmpq *0x1fec(%rip) # 0x2ff8 <_GLOBAL_OFFSET_TABLE_+0x10>
100c: 0f 1f 40 00 nopl (%rax)
0000000000001010 <foo1@plt>:
1010: ff 25 ea 1f 00 00 jmpq *0x1fea(%rip) # 0x3000 <_GLOBAL_OFFSET_TABLE_+0x18>
1016: 68 00 00 00 00 pushq $0x0
101b: e9 e0 ff ff ff jmp 0x1000 <.plt>
0000000000001020 <foo0@plt>:
1020: ff 25 e2 1f 00 00 jmpq *0x1fe2(%rip) # 0x3008 <_GLOBAL_OFFSET_TABLE_+0x20>
1026: 68 01 00 00 00 pushq $0x1
102b: e9 d0 ff ff ff jmp 0x1000 <.plt>
Disassembly of section .plt.got:
0000000000001030 <combined0@plt>:
1030: ff 25 a2 1f 00 00 jmpq *0x1fa2(%rip) # 0x2fd8 <foo1+0x2fd8>
1036: 66 90 nop
0000000000001038 <combined1@plt>:
1038: ff 25 a2 1f 00 00 jmpq *0x1fa2(%rip) # 0x2fe0 <foo1+0x2fe0>
103e: 66 90 nop
```
For x86-32, with -z now, if we remove `foo0` and `foo1`, the absence of regular
PLT will cause GNU ld to omit .got.plt, and our code cannot synthesize @plt
labels. This is an extreme corner case that almost never happens in practice (to
trigger the case, ensure every PLT symbol has been taken address). To fix it, we
can get the `_GLOBAL_OFFSET_TABLE_` symbol value, but the complexity is not
worth it.
Close https://github.com/llvm/llvm-project/issues/62537
Reviewed By: bd1976llvm
Differential Revision: https://reviews.llvm.org/D149817
