D63847 added `MCInstrAnalysis::evaluateMemoryOperandAddress()`. This patch
leverages the feature to print the target addresses for evaluable instructions.
```
-400a: movl 4080(%rip), %eax
+400a: movl 4080(%rip), %eax # 5000 <data1>
```
This patch also deletes `MIA->isCall(Inst) || MIA->isUnconditionalBranch(Inst) || MIA->isConditionalBranch(Inst)`
which is used to guard `MCInstrAnalysis::evaluateBranch()`
Reviewed By: jhenderson, skan
Differential Revision: https://reviews.llvm.org/D78776
Prior to this patch, llvm-objdump would only look in the last section
(according to the section header table order) that matched an address
for a symbol when identifying the target symbol of a call or branch
operation. If there are multiple sections with the same address, due to
some of them being empty, it did not look in those, even if the symbol
couldn't be found in the first section looked in.
This patch causes llvm-objdump to look in all sections for possible
candidate symbols. If there are multiple possible symbols, it picks one
from a non-empty section, if possible (as that is more likely to be the
"real" symbol since functions can't really be in emptiy sections),
before falling back to those in empty sections. If all else fails, it
falls back to absolute symbols as it did before.
Differential Revision: https://reviews.llvm.org/D78549
Reviewed by: grimar, Higuoxing
Currently C++ symbols are demangled in the symbol table as well as in
the disassembly and relocations. This patch adds demangling of C++
symbols in targets of calls and branches making it easier to decipher
control flow in disassembly. This also matches up with GNUobjdump's
behavior
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D77957
When two sections shared the same address, the disassembly code was
using pointer values when sorting (see the SectionRef less than
operator). Since those values aren't guaranteed to have a specific
order, this meant the disassembly code would sometimes change which
section to pick when finding symbols targeted by calls in fully linked
objects.
This change fixes the non-determinism, so that the same section is
always picked. This might have a negative impact in that now a section
without any symbol might be picked over a section with symbols, but this
will be addressed in a later commit.
Fixes https://bugs.llvm.org/show_bug.cgi?id=45411.
Reviewed by: grimar, MaskRay
Differential Revision: https://reviews.llvm.org/D77640
Summary:
This patch is to teach `llvm-objdump` dump dynamic symbols (`-T` and `--dynamic-syms`). Currently, this patch is not fully compatible with `gnu-objdump`, but I would like to continue working on this in next few patches. It has two issues.
1. Some symbols shouldn't be marked as global(g). (`-t/--syms` has same issue as well) (Fixed by D75659)
2. `gnu-objdump` can dump version information and *dynamically* insert before symbol name field.
`objdump -T a.out` gives:
```
DYNAMIC SYMBOL TABLE:
0000000000000000 w D *UND* 0000000000000000 _ITM_deregisterTMCloneTable
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 printf
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 __libc_start_main
0000000000000000 w D *UND* 0000000000000000 __gmon_start__
0000000000000000 w D *UND* 0000000000000000 _ITM_registerTMCloneTable
0000000000000000 w DF *UND* 0000000000000000 GLIBC_2.2.5 __cxa_finalize
```
`llvm-objdump -T a.out` gives:
```
DYNAMIC SYMBOL TABLE:
0000000000000000 w D *UND* 0000000000000000 _ITM_deregisterTMCloneTable
0000000000000000 g DF *UND* 0000000000000000 printf
0000000000000000 g DF *UND* 0000000000000000 __libc_start_main
0000000000000000 w D *UND* 0000000000000000 __gmon_start__
0000000000000000 w D *UND* 0000000000000000 _ITM_registerTMCloneTable
0000000000000000 w DF *UND* 0000000000000000 __cxa_finalize
```
Reviewers: jhenderson, grimar, MaskRay, espindola
Reviewed By: jhenderson, grimar
Subscribers: emaste, rupprecht, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D75756
```
// llvm-objdump -d output (before)
400000: e8 0b 00 00 00 callq 11
400005: e8 0b 00 00 00 callq 11
// llvm-objdump -d output (after)
400000: e8 0b 00 00 00 callq 0x400010
400005: e8 0b 00 00 00 callq 0x400015
// GNU objdump -d. The lack of 0x is not ideal because the result cannot be re-assembled
400000: e8 0b 00 00 00 callq 400010
400005: e8 0b 00 00 00 callq 400015
```
In llvm-objdump, we pass the address of the next MCInst. Ideally we
should just thread the address of the current address, unfortunately we
cannot call X86MCCodeEmitter::encodeInstruction (X86MCCodeEmitter
requires MCInstrInfo and MCContext) to get the length of the MCInst.
MCInstPrinter::printInst has other callers (e.g llvm-mc -filetype=asm, llvm-mca) which set Address to 0.
They leave MCInstPrinter::PrintBranchImmAsAddress as false and this change is a no-op for them.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D76580
`PAddr` corresponds to `p_paddr` of a program header, which is the segment's physical
address for systems in which physical addressing is relevant. `p_paddr` is often equal
to `p_vaddr`, which is the virtual address of a segment.
This patch changes the default for `PAddr` from 0 to a value of `VAddr`.
Differential revision: https://reviews.llvm.org/D76131
The new behavior matches GNU objdump. A pair of angle brackets makes tests slightly easier.
`.foo:` is not unique and thus cannot be used in a `CHECK-LABEL:` directive.
Without `-LABEL`, the CHECK line can match the `Disassembly of section`
line and causes the next `CHECK-NEXT:` to fail.
```
Disassembly of section .foo:
0000000000001634 .foo:
```
Bdragon: <> has metalinguistic connotation. it just "feels right"
Reviewed By: rupprecht
Differential Revision: https://reviews.llvm.org/D75713
This fixes several issues. The behavior changes are:
A SHN_COMMON symbol does not have the 'g' flag.
An undefined symbol does not have 'g' or 'l' flag.
A STB_GLOBAL SymbolRef::ST_Unknown symbol has the 'g' flag.
A STB_LOCAL SymbolRef::ST_Unknown symbol has the 'l' flag.
Reviewed By: rupprecht
Differential Revision: https://reviews.llvm.org/D75659
Summary:
GNU objdump prints the method name in disassembly output, and upon further investigation this seems to come from debug info, not the symbol table.
Some additional refactoring is necessary to make this work even when the line number is 0/the filename is unknown. The added test case includes a note for this scenario.
See http://llvm.org/PR41341 for more info.
Reviewers: dblaikie, MaskRay, jhenderson
Reviewed By: MaskRay
Subscribers: ormris, jvesely, aprantl, kerbowa, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D74507
Summary:
GNU objdump prints the file format in lowercase, e.g. `elf64-x86-64`. llvm-objdump prints `ELF64-x86-64` right now, even though piping that into llvm-objcopy refuses that as a valid arch to use.
As an example of a problem this causes, see: https://github.com/ClangBuiltLinux/linux/issues/779
Reviewers: MaskRay, jhenderson, alexshap
Reviewed By: MaskRay
Subscribers: tpimh, sbc100, grimar, jvesely, nhaehnle, kerbowa, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D74433
Summary:
llvm-objdump -macho will no longer print "Contents of" headers when
disassembling section contents when -no-leading-headers is specified.
For historical reasons, this flag is independent of -no-leading-addr.
Reviewers: ab, pete, jhenderson
Reviewed By: jhenderson
Subscribers: rupprecht, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D73574
Summary:
llvm-objdump started warning when asked to disassemble a section that
isn't present in the input files, in Yuanfang Chen's change:
d16c162c94. The problem is that the
logic was restricted only to the generic llvm-objdump parser, not to the
Mach-O-specific parser used for Apple toolchain compatibility. The
solution is to log section names from the Mach-O parser.
The macho-cstring-dump.test has been updated to fail if it encounters
this new warning in the future.
Reviewers: pete, ab, lhames, jhenderson, grimar, MaskRay, ychen
Reviewed By: jhenderson, grimar
Subscribers: rupprecht, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D73586
To improve consistency and avoid unneeded shell feature (output
redirection).
While here, make other changes to improve consistency
--docnum 1 => --docnum=1
-docnum=x => --docnum=x
Mostly this adds testing for certain aliases in more explicit ways.
There are also a few tidy-ups, and additions of missing testing, where
the feature was either not tested at all, or not tested explicitly and
sufficiently.
Reviewed by: MaskRay, rupprecht, grimar
Differential Revision: https://reviews.llvm.org/D71116
Summary: Matches GNU objdump. Makes debugging easier for me as I'm working out addresses from symbol+addend, so it would be good to be calculating in a single format.
Reviewers: MaskRay, grimar, jhenderson, bd1976llvm
Reviewed By: jhenderson
Subscribers: sdardis, jrtc27, atanasyan, rupprecht, seiya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D69997
llvm-objdump -D this file:
int a[100000];
int main() { return 0; }
Will produce an error: "The end of the file was unexpectedly encountered".
This happens because of a check in Binary.h checkOffset. (Addr + Size > M.getBufferEnd()).
The sh_offset and sh_size fields can be ignored for SHT_NOBITS sections.
Fix the error by changing ELFObjectFile<ELFT>::getSectionContents to use
the file base for SHT_NOBITS sections.
Reviewed By: grimar, MaskRay
Differential Revision: https://reviews.llvm.org/D69192
It returns just a section_iterator currently and have a report_fatal_error call inside.
This change adds a way to return errors and handle them on caller sides.
The patch also changes/improves current users and adds test cases.
Differential revision: https://reviews.llvm.org/D69167
llvm-svn: 375408
Summary:
rL371826 rearranged some output from llvm-objdump for GNU objdump compatability, but there still seem to be some more.
I think this rearrangement is a little closer. Overview of the ordering which matches GNU objdump:
* Archive headers
* File headers
* Section headers
* Symbol table
* Dwarf debugging
* Relocations (if `--disassemble` is not used)
* Section contents
* Disassembly
Reviewers: jhenderson, justice_adams, grimar, ychen, espindola
Reviewed By: jhenderson
Subscribers: aprantl, emaste, arichardson, jrtc27, atanasyan, seiya, llvm-commits, MaskRay
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68066
llvm-svn: 373671
The error reporting function are not consistent.
Before this change:
* They had inconsistent naming (e.g. 'error' vs 'report_error').
* Some of them reported the object name, others - dont.
* Some of them accepted the case when there was no error. (i.e. error code or Error had a success value).
This patch tries to cleanup it a bit.
It also renames report_error -> reportError, report_warning -> reportWarning
and removes a full stop from messages.
Differential revision: https://reviews.llvm.org/D66418
llvm-svn: 369515
There are 2 similar openbsd-phdrs.elf-x86-64 objects committed and
used in test/Object and test/tools/llvm-objdump test cases.
There is no reason to have them, we can use YAML instead. Patch does that.
Differential revision: https://reviews.llvm.org/D66342
llvm-svn: 369189
This patch removes test/Object/X86/no-start-symbol.test (rewrites
it to use YAML and moves it to llvm-objdump tests folder).
(This test was initially introduced in rL239039, but now there
is no reason to keep the precompiled binary it seems).
DIfferential revision: https://reviews.llvm.org/D65136
llvm-svn: 366896
Currently, the symbolizer lib can only symbolize a file on disk.
This patch teaches the symbolizer lib to symbolize objects.
llvm-objdump needs this to support archive disassembly with source info.
https://bugs.llvm.org/show_bug.cgi?id=41871
Reviewed by: jhenderson, grimar, MaskRay
Differential Revision: https://reviews.llvm.org/D63521
llvm-svn: 365376
Mac Catalyst is a new MachO platform in macOS Catalina.
It always uses the build_version MachO load command.
Differential Revision: https://reviews.llvm.org/D64107
llvm-svn: 364981
-d code.
Summary:
Move it into `main` function so the checking is effective for all actions
user may do with llvm-objdump; notably, -r and -s in addition to existing -d.
Match GNU behavior.
Reviewers: jhenderson, grimar, MaskRay, rupprecht
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63631
llvm-svn: 364118
Summary:
Historically llvm-objdump prints the path to a dylib as well as the
dylib's compatibility version and current version number. This change
extends this information by adding the kind of dylib load: weak,
reexport, etc.
rdar://51383512
Reviewers: pete, lhames
Reviewed By: pete
Subscribers: rupprecht, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62866
llvm-svn: 363746
Fangrui Song