```
// 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
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 improves readability and the behavior is consistent with GNU objdump.
The new test test/tools/llvm-objdump/X86/disassemble-section-name.s
checks we print newlines before and after "Disassembly of section ...:"
Differential Revision: https://reviews.llvm.org/D61127
llvm-svn: 359668
Noticed while testing for an out of tree target. There are probably more tests that should be so marked.
I'm not sure who owns these tests so I've added a few names I recognise from the recent history.
With advice from probinson, ruiu, rafael and dramatically improved by davidb. Thank you all!
Differential Revision: https://reviews.llvm.org/D34685
llvm-svn: 308335
Currently the freebsd early boot code fails to link. The issue reduces
to 16 bit code at position 0x7000 wanting to jump to position
0x9000. That is represented in the .o file as a relocation with no
symbol and an addend of 0x9000 - 2 (The -2 is because i386 uses the ip
after the current instruction for jumps).
If the addend is interpreted as signed (it should), it is -28674. In a
32 bit architecture, that is the address 0xffff8ffe. To get there from
0x7000 we have to add 4294909950 (too big) or subtract 57346 (too
small). We then produce an error.
What lld is missing is the fact that at runtime this will actually be
a 16 bit architecture and adding 0x1ffe produces 0x8ffe which is the
correct result in 16 bits (-28674).
Since we have a 16 bit addend and a 16 bit PC, the relocation can move
the PC to any 16 bit address and that is the only thing we really need
to check: if the address we are pointing to fits in 16 bits. This is
unfortunately hard to do since we have to delay subtracting the PC and
if we want to do that outside of Target.cpp, we have to move the
overflow check out too. An incomplete patch that tries to do that is
at https://reviews.llvm.org/D34070
This patch instead just relaxes the check. Since the value we have is
the destination minus the PC and the PC is 16 bits, it should fit in
17 bits if the destination fits in 16 too.
bfd had a similar issue for some time and got a similar fix:
https://sourceware.org/ml/binutils/2005-08/msg00001.html
llvm-svn: 305135
Fangrui Song