llvm-objdump should provide some way of printing out the addends present in the
.rela sections for debugging purposes if nothing else.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184072 91177308-0d34-0410-b5e6-96231b3b80d8
For COFF and MachO, sections semantically have relocations that apply to them.
That is not the case on ELF.
In relocatable objects (.o), a section with relocations in ELF has offsets to
another section where the relocations should be applied.
In dynamic objects and executables, relocations don't have an offset, they have
a virtual address. The section sh_info may or may not point to another section,
but that is not actually used for resolving the relocations.
This patch exposes that in the ObjectFile API. It has the following advantages:
* Most (all?) clients can handle this more efficiently. They will normally walk
all relocations, so doing an effort to iterate in a particular order doesn't
save time.
* llvm-readobj now prints relocations in the same way the native readelf does.
* probably most important, relocations that don't point to any section are now
visible. This is the case of relocations in the rela.dyn section. See the
updated relocation-executable.test for example.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182908 91177308-0d34-0410-b5e6-96231b3b80d8
These tests rely specifically on the names of ELF relocations, let alone any
other detail. There's no way they'd work if LLVM was emitting something else by
default.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179376 91177308-0d34-0410-b5e6-96231b3b80d8
It turns out some platforms (e.g. Windows) lay out their llvm-mc slightly
differently with extra newlines; there was no real reason for the test lines to
be consecutive, so this relaxes the FileCheck.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179375 91177308-0d34-0410-b5e6-96231b3b80d8
This gives a DiagnosticType to all AsmOperands in sight. This replaces all
"invalid operand" diagnostics with something more specific. The messages given
should still be sufficiently vague that they're not usually actively misleading
when LLVM guesses your instruction incorrectly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174871 91177308-0d34-0410-b5e6-96231b3b80d8
These instructions are a late addition to the architecture, and may
yet end up behind an optional attribute, but for now they're available
at all times.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174496 91177308-0d34-0410-b5e6-96231b3b80d8
This adds hints to the various "prfm" instructions so that they can
affect the instruction cache as well as the data cache.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174495 91177308-0d34-0410-b5e6-96231b3b80d8
Only Linux is supported at the moment, and other platforms quickly fault. As a
result these tests would fail on non-Linux hosts. It may be worth making the
tests more generic again as more platforms are supported.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174170 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds support for AArch64 (ARM's 64-bit architecture) to
LLVM in the "experimental" category. Currently, it won't be built
unless requested explicitly.
This initial commit should have support for:
+ Assembly of all scalar (i.e. non-NEON, non-Crypto) instructions
(except the late addition CRC instructions).
+ CodeGen features required for C++03 and C99.
+ Compilation for the "small" memory model: code+static data <
4GB.
+ Absolute and position-independent code.
+ GNU-style (i.e. "__thread") TLS.
+ Debugging information.
The principal omission, currently, is performance tuning.
This patch excludes the NEON support also reviewed due to an outbreak of
batshit insanity in our legal department. That will be committed soon bringing
the changes to precisely what has been approved.
Further reviews would be gratefully received.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174054 91177308-0d34-0410-b5e6-96231b3b80d8
