maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/lib/Object/ELFObjectFile.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

650 lines
18 KiB
C++
Raw Normal View History

[Object] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 301275
2017-04-25 07:21:38 +08:00
//===- ELFObjectFile.cpp - ELF object file implementation -----------------===//
Object: Add ELF support. llvm-svn: 123896
2011-01-20 14:38:47 +08:00
//
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2019-01-19 16:50:56 +08:00
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
Object: Add ELF support. llvm-svn: 123896
2011-01-20 14:38:47 +08:00
//
//===----------------------------------------------------------------------===//
//
Expose the ELFObjectFile class directly in the Object/ELF.h header, similarly to what's done for MachO and COFF. This allows advanced uses of the class to be implemented outside the Object library. In particular, the DyldELFObject subclass is now moved into its logical home - ExecutionEngine/RuntimeDyld. This patch was reviewed by Michael Spencer. llvm-svn: 150327
2012-02-12 14:12:10 +08:00
// Part of the ELFObjectFile class implementation.
Object: Add ELF support. llvm-svn: 123896
2011-01-20 14:38:47 +08:00
//
//===----------------------------------------------------------------------===//
Sort the remaining #include lines in include/... and lib/.... I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
2017-06-06 19:49:48 +08:00
#include "llvm/Object/ELFObjectFile.h"
[Object] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 301275
2017-04-25 07:21:38 +08:00
#include "llvm/ADT/Triple.h"
Move Object format code to lib/BinaryFormat. This creates a new library called BinaryFormat that has all of the headers from llvm/Support containing structure and layout definitions for various types of binary formats like dwarf, coff, elf, etc as well as the code for identifying a file from its magic. Differential Revision: https://reviews.llvm.org/D33843 llvm-svn: 304864
2017-06-07 11:48:56 +08:00
#include "llvm/BinaryFormat/ELF.h"
Find PLT entries for x86, x86_64, and AArch64. This adds a new method to ELFObjectFileBase that returns the symbols and addresses of PLT entries. This design was suggested by pcc and eugenis in https://reviews.llvm.org/D49383. Differential Revision: https://reviews.llvm.org/D50203 llvm-svn: 340610
2018-08-24 23:21:56 +08:00
#include "llvm/MC/MCInstrAnalysis.h"
[Object] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 301275
2017-04-25 07:21:38 +08:00
#include "llvm/MC/SubtargetFeature.h"
#include "llvm/Object/ELF.h"
#include "llvm/Object/ELFTypes.h"
#include "llvm/Object/Error.h"
[ARM] Create SubtargetFeatures from build attrs An ELFObjectFile can now create SubtargetFeatures from the available ARM build attributes, in a similar manner to MIPS. I've moved the MIPS code into its own function and the ARM handler also has a separate function. Differential Revision: https://reviews.llvm.org/D28291 llvm-svn: 292403
2017-01-18 23:52:11 +08:00
#include "llvm/Support/ARMAttributeParser.h"
Sort the remaining #include lines in include/... and lib/.... I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
2017-06-06 19:49:48 +08:00
#include "llvm/Support/ARMBuildAttributes.h"
[Object] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 301275
2017-04-25 07:21:38 +08:00
#include "llvm/Support/Endian.h"
#include "llvm/Support/ErrorHandling.h"
[Object][ELF] Add a maximum alignment. This is used by createELFObjectFile to create a properly aligned reader. llvm-svn: 171520
2013-01-05 04:36:28 +08:00
#include "llvm/Support/MathExtras.h"
[RISCV] ELF attribute section for RISC-V. Leverage ARM ELF build attribute section to create ELF attribute section for RISC-V. Extract the common part of parsing logic for this section into ELFAttributeParser.[cpp|h] and ELFAttributes.[cpp|h]. Differential Revision: https://reviews.llvm.org/D74023
2020-02-04 22:20:10 +08:00
#include "llvm/Support/RISCVAttributeParser.h"
#include "llvm/Support/RISCVAttributes.h"
Find PLT entries for x86, x86_64, and AArch64. This adds a new method to ELFObjectFileBase that returns the symbols and addresses of PLT entries. This design was suggested by pcc and eugenis in https://reviews.llvm.org/D49383. Differential Revision: https://reviews.llvm.org/D50203 llvm-svn: 340610
2018-08-24 23:21:56 +08:00
#include "llvm/Support/TargetRegistry.h"
[Object] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 301275
2017-04-25 07:21:38 +08:00
#include <algorithm>
#include <cstddef>
#include <cstdint>
#include <memory>
#include <string>
#include <system_error>
#include <utility>
Object: Add ELF support. llvm-svn: 123896
2011-01-20 14:38:47 +08:00
[Object] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 301275
2017-04-25 07:21:38 +08:00
using namespace llvm;
Expose the ELFObjectFile class directly in the Object/ELF.h header, similarly to what's done for MachO and COFF. This allows advanced uses of the class to be implemented outside the Object library. In particular, the DyldELFObject subclass is now moved into its logical home - ExecutionEngine/RuntimeDyld. This patch was reviewed by Michael Spencer. llvm-svn: 150327
2012-02-12 14:12:10 +08:00
using namespace object;
Add support for relocations to ObjectFile. Patch by Danil Malyshev! llvm-svn: 139314
2011-09-09 04:52:17 +08:00
Improve "llvm-nm -f sysv" output for Elf files Specifically, compute and Print Type and Section columns. This is a re-commit of rL354833, after fixing the Asan problem found a a buildbot. Differential Revision: https://reviews.llvm.org/D59060 llvm-svn: 355742
2019-03-09 06:00:50 +08:00
const EnumEntry<unsigned> llvm::object::ElfSymbolTypes[NumElfSymbolTypes] = {
{"None", "NOTYPE", ELF::STT_NOTYPE},
{"Object", "OBJECT", ELF::STT_OBJECT},
{"Function", "FUNC", ELF::STT_FUNC},
{"Section", "SECTION", ELF::STT_SECTION},
{"File", "FILE", ELF::STT_FILE},
{"Common", "COMMON", ELF::STT_COMMON},
{"TLS", "TLS", ELF::STT_TLS},
Print reasonable representations of type names in llvm-nm, readelf and readobj For type values that do not have proper names, print reasonable representation in llvm-nm, llvm-readobj and llvm-readelf, matching GNU tools.s Fixes PR41713. Differential Revision: https://reviews.llvm.org/D65537 llvm-svn: 368451
2019-08-10 00:54:51 +08:00
{"Unknown", "<unknown>: 7", 7},
{"Unknown", "<unknown>: 8", 8},
{"Unknown", "<unknown>: 9", 9},
{"GNU_IFunc", "IFUNC", ELF::STT_GNU_IFUNC},
{"OS Specific", "<OS specific>: 11", 11},
{"OS Specific", "<OS specific>: 12", 12},
{"Proc Specific", "<processor specific>: 13", 13},
{"Proc Specific", "<processor specific>: 14", 14},
{"Proc Specific", "<processor specific>: 15", 15}
};
Improve "llvm-nm -f sysv" output for Elf files Specifically, compute and Print Type and Section columns. This is a re-commit of rL354833, after fixing the Asan problem found a a buildbot. Differential Revision: https://reviews.llvm.org/D59060 llvm-svn: 355742
2019-03-09 06:00:50 +08:00
Don't own the buffer in object::Binary. Owning the buffer is somewhat inflexible. Some Binaries have sub Binaries (like Archive) and we had to create dummy buffers just to handle that. It is also a bad fit for IRObjectFile where the Module wants to own the buffer too. Keeping this ownership would make supporting IR inside native objects particularly painful. This patch focuses in lib/Object. If something elsewhere used to own an Binary, now it also owns a MemoryBuffer. This patch introduces a few new types. * MemoryBufferRef. This is just a pair of StringRefs for the data and name. This is to MemoryBuffer as StringRef is to std::string. * OwningBinary. A combination of Binary and a MemoryBuffer. This is needed for convenience functions that take a filename and return both the buffer and the Binary using that buffer. The C api now uses OwningBinary to avoid any change in semantics. I will start a new thread to see if we want to change it and how. llvm-svn: 216002
2014-08-20 02:44:46 +08:00
ELFObjectFileBase::ELFObjectFileBase(unsigned int Type, MemoryBufferRef Source)
: ObjectFile(Type, Source) {}
Add a non-templated ELFObjectFileBase class. Use it to implement some ELF only virtual interfaces instead of using error prone series of dyn_casts. llvm-svn: 215838
2014-08-18 01:52:10 +08:00
Make the ELFObjectFile constructor private. This forces every user to use the new create method that returns an Expected. This in turn propagates better error messages. llvm-svn: 315371
2017-10-11 05:21:16 +08:00
template <class ELFT>
static Expected<std::unique_ptr<ELFObjectFile<ELFT>>>
Recommit: [llvm-readelf/obj] - Allow dumping of ELF header even if some elements are corrupt. This is recommit for D90903 with fixes for BB: 1) Used std::move<> when returning Expected<> (http://lab.llvm.org:8011/#/builders/112/builds/913) 2) Fixed the name of temporarily file in the file-headers.test (http://lab.llvm.org:8011/#/builders/36/builds/1269) (a local old temporarily file was used before) For creating `ELFObjectFile` instances we have the factory method `ELFObjectFile<ELFT>::create(MemoryBufferRef Object)`. The problem of this method is that it scans the section header to locate some sections. When a file is truncated or has broken fields in the ELF header, this approach does not allow us to create the `ELFObjectFile` and dump the ELF header. This is https://bugs.llvm.org/show_bug.cgi?id=40804 This patch suggests a solution - it allows to delay scaning sections in the `ELFObjectFile<ELFT>::create`. It now allows user code to call an object initialization (`initContent()`) later. With that it is possible, for example, for dumpers just to dump the file header and exit. By default initialization is still performed as before, what helps to keep the logic of existent callers untouched. I've experimented with different approaches when worked on this patch. I think this approach is better than doing initialization of sections (i.e. scan of them) on demand, because normally users of `ELFObjectFile` API expect to work with a valid object. In most cases when a section header table can't be read (because of an error), we don't have to continue to work with object. So we probably don't need to implement a more complex API. Differential revision: https://reviews.llvm.org/D90903
2020-11-09 17:18:18 +08:00
createPtr(MemoryBufferRef Object, bool InitContent) {
auto Ret = ELFObjectFile<ELFT>::create(Object, InitContent);
Make the ELFObjectFile constructor private. This forces every user to use the new create method that returns an Expected. This in turn propagates better error messages. llvm-svn: 315371
2017-10-11 05:21:16 +08:00
if (Error E = Ret.takeError())
Revert "Remove redundant "std::move"s in return statements" The build failed with error: call to deleted constructor of 'llvm::Error' errors. This reverts commit 1c2241a7936bf85aa68aef94bd40c3ba77d8ddf2.
2020-02-10 23:06:45 +08:00
return std::move(E);
[llvm] Migrate llvm::make_unique to std::make_unique Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. llvm-svn: 369013
2019-08-15 23:54:37 +08:00
return std::make_unique<ELFObjectFile<ELFT>>(std::move(*Ret));
Make the ELFObjectFile constructor private. This forces every user to use the new create method that returns an Expected. This in turn propagates better error messages. llvm-svn: 315371
2017-10-11 05:21:16 +08:00
}
Convert two uses of ErrorOr to Expected. llvm-svn: 315354
2017-10-11 04:00:07 +08:00
Expected<std::unique_ptr<ObjectFile>>
Recommit: [llvm-readelf/obj] - Allow dumping of ELF header even if some elements are corrupt. This is recommit for D90903 with fixes for BB: 1) Used std::move<> when returning Expected<> (http://lab.llvm.org:8011/#/builders/112/builds/913) 2) Fixed the name of temporarily file in the file-headers.test (http://lab.llvm.org:8011/#/builders/36/builds/1269) (a local old temporarily file was used before) For creating `ELFObjectFile` instances we have the factory method `ELFObjectFile<ELFT>::create(MemoryBufferRef Object)`. The problem of this method is that it scans the section header to locate some sections. When a file is truncated or has broken fields in the ELF header, this approach does not allow us to create the `ELFObjectFile` and dump the ELF header. This is https://bugs.llvm.org/show_bug.cgi?id=40804 This patch suggests a solution - it allows to delay scaning sections in the `ELFObjectFile<ELFT>::create`. It now allows user code to call an object initialization (`initContent()`) later. With that it is possible, for example, for dumpers just to dump the file header and exit. By default initialization is still performed as before, what helps to keep the logic of existent callers untouched. I've experimented with different approaches when worked on this patch. I think this approach is better than doing initialization of sections (i.e. scan of them) on demand, because normally users of `ELFObjectFile` API expect to work with a valid object. In most cases when a section header table can't be read (because of an error), we don't have to continue to work with object. So we probably don't need to implement a more complex API. Differential revision: https://reviews.llvm.org/D90903
2020-11-09 17:18:18 +08:00
ObjectFile::createELFObjectFile(MemoryBufferRef Obj, bool InitContent) {
This only needs a StringRef. No functionality change. llvm-svn: 212371
2014-07-05 19:38:52 +08:00
std::pair<unsigned char, unsigned char> Ident =
Don't own the buffer in object::Binary. Owning the buffer is somewhat inflexible. Some Binaries have sub Binaries (like Archive) and we had to create dummy buffers just to handle that. It is also a bad fit for IRObjectFile where the Module wants to own the buffer too. Keeping this ownership would make supporting IR inside native objects particularly painful. This patch focuses in lib/Object. If something elsewhere used to own an Binary, now it also owns a MemoryBuffer. This patch introduces a few new types. * MemoryBufferRef. This is just a pair of StringRefs for the data and name. This is to MemoryBuffer as StringRef is to std::string. * OwningBinary. A combination of Binary and a MemoryBuffer. This is needed for convenience functions that take a filename and return both the buffer and the Binary using that buffer. The C api now uses OwningBinary to avoid any change in semantics. I will start a new thread to see if we want to change it and how. llvm-svn: 216002
2014-08-20 02:44:46 +08:00
getElfArchType(Obj.getBuffer());
[Object][ELF] Add a maximum alignment. This is used by createELFObjectFile to create a properly aligned reader. llvm-svn: 171520
2013-01-05 04:36:28 +08:00
std::size_t MaxAlignment =
Replace `T(x)` with `reinterpret_cast<T>(x)` everywhere it means reinterpret_cast. NFC. Differential Revision: https://reviews.llvm.org/D76572
2020-03-23 10:20:04 +08:00
1ULL << countTrailingZeros(
reinterpret_cast<uintptr_t>(Obj.getBufferStart()));
[Object][ELF] Add a maximum alignment. This is used by createELFObjectFile to create a properly aligned reader. llvm-svn: 171520
2013-01-05 04:36:28 +08:00
Simplify now that we always use an alignment of 2 for ELF files. This saves 123144 bytes out of llvm-nm on powerpc64le. llvm-svn: 238824
2015-06-02 20:05:27 +08:00
if (MaxAlignment < 2)
Convert two uses of ErrorOr to Expected. llvm-svn: 315354
2017-10-11 04:00:07 +08:00
return createError("Insufficient alignment");
Simplify now that we always use an alignment of 2 for ELF files. This saves 123144 bytes out of llvm-nm on powerpc64le. llvm-svn: 238824
2015-06-02 20:05:27 +08:00
if (Ident.first == ELF::ELFCLASS32) {
if (Ident.second == ELF::ELFDATA2LSB)
Recommit: [llvm-readelf/obj] - Allow dumping of ELF header even if some elements are corrupt. This is recommit for D90903 with fixes for BB: 1) Used std::move<> when returning Expected<> (http://lab.llvm.org:8011/#/builders/112/builds/913) 2) Fixed the name of temporarily file in the file-headers.test (http://lab.llvm.org:8011/#/builders/36/builds/1269) (a local old temporarily file was used before) For creating `ELFObjectFile` instances we have the factory method `ELFObjectFile<ELFT>::create(MemoryBufferRef Object)`. The problem of this method is that it scans the section header to locate some sections. When a file is truncated or has broken fields in the ELF header, this approach does not allow us to create the `ELFObjectFile` and dump the ELF header. This is https://bugs.llvm.org/show_bug.cgi?id=40804 This patch suggests a solution - it allows to delay scaning sections in the `ELFObjectFile<ELFT>::create`. It now allows user code to call an object initialization (`initContent()`) later. With that it is possible, for example, for dumpers just to dump the file header and exit. By default initialization is still performed as before, what helps to keep the logic of existent callers untouched. I've experimented with different approaches when worked on this patch. I think this approach is better than doing initialization of sections (i.e. scan of them) on demand, because normally users of `ELFObjectFile` API expect to work with a valid object. In most cases when a section header table can't be read (because of an error), we don't have to continue to work with object. So we probably don't need to implement a more complex API. Differential revision: https://reviews.llvm.org/D90903
2020-11-09 17:18:18 +08:00
return createPtr<ELF32LE>(Obj, InitContent);
Simplify now that we always use an alignment of 2 for ELF files. This saves 123144 bytes out of llvm-nm on powerpc64le. llvm-svn: 238824
2015-06-02 20:05:27 +08:00
else if (Ident.second == ELF::ELFDATA2MSB)
Recommit: [llvm-readelf/obj] - Allow dumping of ELF header even if some elements are corrupt. This is recommit for D90903 with fixes for BB: 1) Used std::move<> when returning Expected<> (http://lab.llvm.org:8011/#/builders/112/builds/913) 2) Fixed the name of temporarily file in the file-headers.test (http://lab.llvm.org:8011/#/builders/36/builds/1269) (a local old temporarily file was used before) For creating `ELFObjectFile` instances we have the factory method `ELFObjectFile<ELFT>::create(MemoryBufferRef Object)`. The problem of this method is that it scans the section header to locate some sections. When a file is truncated or has broken fields in the ELF header, this approach does not allow us to create the `ELFObjectFile` and dump the ELF header. This is https://bugs.llvm.org/show_bug.cgi?id=40804 This patch suggests a solution - it allows to delay scaning sections in the `ELFObjectFile<ELFT>::create`. It now allows user code to call an object initialization (`initContent()`) later. With that it is possible, for example, for dumpers just to dump the file header and exit. By default initialization is still performed as before, what helps to keep the logic of existent callers untouched. I've experimented with different approaches when worked on this patch. I think this approach is better than doing initialization of sections (i.e. scan of them) on demand, because normally users of `ELFObjectFile` API expect to work with a valid object. In most cases when a section header table can't be read (because of an error), we don't have to continue to work with object. So we probably don't need to implement a more complex API. Differential revision: https://reviews.llvm.org/D90903
2020-11-09 17:18:18 +08:00
return createPtr<ELF32BE>(Obj, InitContent);
Simplify now that we always use an alignment of 2 for ELF files. This saves 123144 bytes out of llvm-nm on powerpc64le. llvm-svn: 238824
2015-06-02 20:05:27 +08:00
else
Convert two uses of ErrorOr to Expected. llvm-svn: 315354
2017-10-11 04:00:07 +08:00
return createError("Invalid ELF data");
[Object, ELF] Don't assert on invalid magic in createELFObjectFile. Instead, return a proper error code from factory. llvm-svn: 239116
2015-06-05 07:14:43 +08:00
} else if (Ident.first == ELF::ELFCLASS64) {
Simplify now that we always use an alignment of 2 for ELF files. This saves 123144 bytes out of llvm-nm on powerpc64le. llvm-svn: 238824
2015-06-02 20:05:27 +08:00
if (Ident.second == ELF::ELFDATA2LSB)
Recommit: [llvm-readelf/obj] - Allow dumping of ELF header even if some elements are corrupt. This is recommit for D90903 with fixes for BB: 1) Used std::move<> when returning Expected<> (http://lab.llvm.org:8011/#/builders/112/builds/913) 2) Fixed the name of temporarily file in the file-headers.test (http://lab.llvm.org:8011/#/builders/36/builds/1269) (a local old temporarily file was used before) For creating `ELFObjectFile` instances we have the factory method `ELFObjectFile<ELFT>::create(MemoryBufferRef Object)`. The problem of this method is that it scans the section header to locate some sections. When a file is truncated or has broken fields in the ELF header, this approach does not allow us to create the `ELFObjectFile` and dump the ELF header. This is https://bugs.llvm.org/show_bug.cgi?id=40804 This patch suggests a solution - it allows to delay scaning sections in the `ELFObjectFile<ELFT>::create`. It now allows user code to call an object initialization (`initContent()`) later. With that it is possible, for example, for dumpers just to dump the file header and exit. By default initialization is still performed as before, what helps to keep the logic of existent callers untouched. I've experimented with different approaches when worked on this patch. I think this approach is better than doing initialization of sections (i.e. scan of them) on demand, because normally users of `ELFObjectFile` API expect to work with a valid object. In most cases when a section header table can't be read (because of an error), we don't have to continue to work with object. So we probably don't need to implement a more complex API. Differential revision: https://reviews.llvm.org/D90903
2020-11-09 17:18:18 +08:00
return createPtr<ELF64LE>(Obj, InitContent);
Simplify now that we always use an alignment of 2 for ELF files. This saves 123144 bytes out of llvm-nm on powerpc64le. llvm-svn: 238824
2015-06-02 20:05:27 +08:00
else if (Ident.second == ELF::ELFDATA2MSB)
Recommit: [llvm-readelf/obj] - Allow dumping of ELF header even if some elements are corrupt. This is recommit for D90903 with fixes for BB: 1) Used std::move<> when returning Expected<> (http://lab.llvm.org:8011/#/builders/112/builds/913) 2) Fixed the name of temporarily file in the file-headers.test (http://lab.llvm.org:8011/#/builders/36/builds/1269) (a local old temporarily file was used before) For creating `ELFObjectFile` instances we have the factory method `ELFObjectFile<ELFT>::create(MemoryBufferRef Object)`. The problem of this method is that it scans the section header to locate some sections. When a file is truncated or has broken fields in the ELF header, this approach does not allow us to create the `ELFObjectFile` and dump the ELF header. This is https://bugs.llvm.org/show_bug.cgi?id=40804 This patch suggests a solution - it allows to delay scaning sections in the `ELFObjectFile<ELFT>::create`. It now allows user code to call an object initialization (`initContent()`) later. With that it is possible, for example, for dumpers just to dump the file header and exit. By default initialization is still performed as before, what helps to keep the logic of existent callers untouched. I've experimented with different approaches when worked on this patch. I think this approach is better than doing initialization of sections (i.e. scan of them) on demand, because normally users of `ELFObjectFile` API expect to work with a valid object. In most cases when a section header table can't be read (because of an error), we don't have to continue to work with object. So we probably don't need to implement a more complex API. Differential revision: https://reviews.llvm.org/D90903
2020-11-09 17:18:18 +08:00
return createPtr<ELF64BE>(Obj, InitContent);
Simplify now that we always use an alignment of 2 for ELF files. This saves 123144 bytes out of llvm-nm on powerpc64le. llvm-svn: 238824
2015-06-02 20:05:27 +08:00
else
Convert two uses of ErrorOr to Expected. llvm-svn: 315354
2017-10-11 04:00:07 +08:00
return createError("Invalid ELF data");
Reapply r141605 with fixes for appropriate handling of reserved section numbers in st_shndx fields. llvm-svn: 141639
2011-10-11 11:18:58 +08:00
}
Make the ELFObjectFile constructor private. This forces every user to use the new create method that returns an Expected. This in turn propagates better error messages. llvm-svn: 315371
2017-10-11 05:21:16 +08:00
return createError("Invalid ELF class");
Add support for relocations to ObjectFile. Patch by Danil Malyshev! llvm-svn: 139314
2011-09-09 04:52:17 +08:00
}
[ARM] Create SubtargetFeatures from build attrs An ELFObjectFile can now create SubtargetFeatures from the available ARM build attributes, in a similar manner to MIPS. I've moved the MIPS code into its own function and the ARM handler also has a separate function. Differential Revision: https://reviews.llvm.org/D28291 llvm-svn: 292403
2017-01-18 23:52:11 +08:00
SubtargetFeatures ELFObjectFileBase::getMIPSFeatures() const {
SubtargetFeatures Features;
Move getPlatformFlags to ELFObjectFileBase and simplify. This removes a few std::error_code results that were ignored on every call. llvm-svn: 323674
2018-01-30 02:27:30 +08:00
unsigned PlatformFlags = getPlatformFlags();
[ARM] Create SubtargetFeatures from build attrs An ELFObjectFile can now create SubtargetFeatures from the available ARM build attributes, in a similar manner to MIPS. I've moved the MIPS code into its own function and the ARM handler also has a separate function. Differential Revision: https://reviews.llvm.org/D28291 llvm-svn: 292403
2017-01-18 23:52:11 +08:00
switch (PlatformFlags & ELF::EF_MIPS_ARCH) {
case ELF::EF_MIPS_ARCH_1:
break;
case ELF::EF_MIPS_ARCH_2:
Features.AddFeature("mips2");
break;
case ELF::EF_MIPS_ARCH_3:
Features.AddFeature("mips3");
break;
case ELF::EF_MIPS_ARCH_4:
Features.AddFeature("mips4");
break;
case ELF::EF_MIPS_ARCH_5:
Features.AddFeature("mips5");
break;
case ELF::EF_MIPS_ARCH_32:
Features.AddFeature("mips32");
break;
case ELF::EF_MIPS_ARCH_64:
Features.AddFeature("mips64");
break;
case ELF::EF_MIPS_ARCH_32R2:
Features.AddFeature("mips32r2");
break;
case ELF::EF_MIPS_ARCH_64R2:
Features.AddFeature("mips64r2");
break;
case ELF::EF_MIPS_ARCH_32R6:
Features.AddFeature("mips32r6");
break;
case ELF::EF_MIPS_ARCH_64R6:
Features.AddFeature("mips64r6");
break;
default:
llvm_unreachable("Unknown EF_MIPS_ARCH value");
}
switch (PlatformFlags & ELF::EF_MIPS_MACH) {
case ELF::EF_MIPS_MACH_NONE:
// No feature associated with this value.
break;
case ELF::EF_MIPS_MACH_OCTEON:
Features.AddFeature("cnmips");
break;
default:
llvm_unreachable("Unknown EF_MIPS_ARCH value");
}
if (PlatformFlags & ELF::EF_MIPS_ARCH_ASE_M16)
Features.AddFeature("mips16");
if (PlatformFlags & ELF::EF_MIPS_MICROMIPS)
Features.AddFeature("micromips");
return Features;
}
[llvm-objdump] Support detection of feature bits from the object and implement this for Mips. Summary: The Mips implementation only covers the feature bits described by the ELF e_flags so far. Mips stores additional feature bits such as MSA in the .MIPS.abiflags section. Also fixed a small bug this revealed where microMIPS wouldn't add the EF_MIPS_MICROMIPS flag when using -filetype=obj. Reviewers: echristo, rafael Subscribers: rafael, mehdi_amini, dsanders, sdardis, llvm-commits Differential Revision: http://reviews.llvm.org/D21125 llvm-svn: 272880
2016-06-16 17:17:03 +08:00
[ARM] Create SubtargetFeatures from build attrs An ELFObjectFile can now create SubtargetFeatures from the available ARM build attributes, in a similar manner to MIPS. I've moved the MIPS code into its own function and the ARM handler also has a separate function. Differential Revision: https://reviews.llvm.org/D28291 llvm-svn: 292403
2017-01-18 23:52:11 +08:00
SubtargetFeatures ELFObjectFileBase::getARMFeatures() const {
SubtargetFeatures Features;
ARMAttributeParser Attributes;
[ARM] Rewrite ARMAttributeParser * Delete boilerplate * Change functions to return `Error` * Test parsing errors * Update callers of ARMAttributeParser::parse() to check the `Error` return value. Since this patch touches nearly everything in the file, I apply http://llvm.org/docs/Proposals/VariableNames.html and change variable names to lower case. Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D75015
2020-02-22 03:32:33 +08:00
if (Error E = getBuildAttributes(Attributes)) {
consumeError(std::move(E));
[ARM] Create SubtargetFeatures from build attrs An ELFObjectFile can now create SubtargetFeatures from the available ARM build attributes, in a similar manner to MIPS. I've moved the MIPS code into its own function and the ARM handler also has a separate function. Differential Revision: https://reviews.llvm.org/D28291 llvm-svn: 292403
2017-01-18 23:52:11 +08:00
return SubtargetFeatures();
[ARM] Rewrite ARMAttributeParser * Delete boilerplate * Change functions to return `Error` * Test parsing errors * Update callers of ARMAttributeParser::parse() to check the `Error` return value. Since this patch touches nearly everything in the file, I apply http://llvm.org/docs/Proposals/VariableNames.html and change variable names to lower case. Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D75015
2020-02-22 03:32:33 +08:00
}
[ARM] Create SubtargetFeatures from build attrs An ELFObjectFile can now create SubtargetFeatures from the available ARM build attributes, in a similar manner to MIPS. I've moved the MIPS code into its own function and the ARM handler also has a separate function. Differential Revision: https://reviews.llvm.org/D28291 llvm-svn: 292403
2017-01-18 23:52:11 +08:00
// both ARMv7-M and R have to support thumb hardware div
bool isV7 = false;
[RISCV] ELF attribute section for RISC-V. Leverage ARM ELF build attribute section to create ELF attribute section for RISC-V. Extract the common part of parsing logic for this section into ELFAttributeParser.[cpp|h] and ELFAttributes.[cpp|h]. Differential Revision: https://reviews.llvm.org/D74023
2020-02-04 22:20:10 +08:00
Optional<unsigned> Attr =
Attributes.getAttributeValue(ARMBuildAttrs::CPU_arch);
if (Attr.hasValue())
isV7 = Attr.getValue() == ARMBuildAttrs::v7;
[ARM] Create SubtargetFeatures from build attrs An ELFObjectFile can now create SubtargetFeatures from the available ARM build attributes, in a similar manner to MIPS. I've moved the MIPS code into its own function and the ARM handler also has a separate function. Differential Revision: https://reviews.llvm.org/D28291 llvm-svn: 292403
2017-01-18 23:52:11 +08:00
[RISCV] ELF attribute section for RISC-V. Leverage ARM ELF build attribute section to create ELF attribute section for RISC-V. Extract the common part of parsing logic for this section into ELFAttributeParser.[cpp|h] and ELFAttributes.[cpp|h]. Differential Revision: https://reviews.llvm.org/D74023
2020-02-04 22:20:10 +08:00
Attr = Attributes.getAttributeValue(ARMBuildAttrs::CPU_arch_profile);
if (Attr.hasValue()) {
switch (Attr.getValue()) {
[ARM] Create SubtargetFeatures from build attrs An ELFObjectFile can now create SubtargetFeatures from the available ARM build attributes, in a similar manner to MIPS. I've moved the MIPS code into its own function and the ARM handler also has a separate function. Differential Revision: https://reviews.llvm.org/D28291 llvm-svn: 292403
2017-01-18 23:52:11 +08:00
case ARMBuildAttrs::ApplicationProfile:
Features.AddFeature("aclass");
[llvm-objdump] Support detection of feature bits from the object and implement this for Mips. Summary: The Mips implementation only covers the feature bits described by the ELF e_flags so far. Mips stores additional feature bits such as MSA in the .MIPS.abiflags section. Also fixed a small bug this revealed where microMIPS wouldn't add the EF_MIPS_MICROMIPS flag when using -filetype=obj. Reviewers: echristo, rafael Subscribers: rafael, mehdi_amini, dsanders, sdardis, llvm-commits Differential Revision: http://reviews.llvm.org/D21125 llvm-svn: 272880
2016-06-16 17:17:03 +08:00
break;
[ARM] Create SubtargetFeatures from build attrs An ELFObjectFile can now create SubtargetFeatures from the available ARM build attributes, in a similar manner to MIPS. I've moved the MIPS code into its own function and the ARM handler also has a separate function. Differential Revision: https://reviews.llvm.org/D28291 llvm-svn: 292403
2017-01-18 23:52:11 +08:00
case ARMBuildAttrs::RealTimeProfile:
Features.AddFeature("rclass");
if (isV7)
Features.AddFeature("hwdiv");
[llvm-objdump] Support detection of feature bits from the object and implement this for Mips. Summary: The Mips implementation only covers the feature bits described by the ELF e_flags so far. Mips stores additional feature bits such as MSA in the .MIPS.abiflags section. Also fixed a small bug this revealed where microMIPS wouldn't add the EF_MIPS_MICROMIPS flag when using -filetype=obj. Reviewers: echristo, rafael Subscribers: rafael, mehdi_amini, dsanders, sdardis, llvm-commits Differential Revision: http://reviews.llvm.org/D21125 llvm-svn: 272880
2016-06-16 17:17:03 +08:00
break;
[ARM] Create SubtargetFeatures from build attrs An ELFObjectFile can now create SubtargetFeatures from the available ARM build attributes, in a similar manner to MIPS. I've moved the MIPS code into its own function and the ARM handler also has a separate function. Differential Revision: https://reviews.llvm.org/D28291 llvm-svn: 292403
2017-01-18 23:52:11 +08:00
case ARMBuildAttrs::MicroControllerProfile:
Features.AddFeature("mclass");
if (isV7)
Features.AddFeature("hwdiv");
[llvm-objdump] Support detection of feature bits from the object and implement this for Mips. Summary: The Mips implementation only covers the feature bits described by the ELF e_flags so far. Mips stores additional feature bits such as MSA in the .MIPS.abiflags section. Also fixed a small bug this revealed where microMIPS wouldn't add the EF_MIPS_MICROMIPS flag when using -filetype=obj. Reviewers: echristo, rafael Subscribers: rafael, mehdi_amini, dsanders, sdardis, llvm-commits Differential Revision: http://reviews.llvm.org/D21125 llvm-svn: 272880
2016-06-16 17:17:03 +08:00
break;
[ARM] Create SubtargetFeatures from build attrs An ELFObjectFile can now create SubtargetFeatures from the available ARM build attributes, in a similar manner to MIPS. I've moved the MIPS code into its own function and the ARM handler also has a separate function. Differential Revision: https://reviews.llvm.org/D28291 llvm-svn: 292403
2017-01-18 23:52:11 +08:00
}
}
[RISCV] ELF attribute section for RISC-V. Leverage ARM ELF build attribute section to create ELF attribute section for RISC-V. Extract the common part of parsing logic for this section into ELFAttributeParser.[cpp|h] and ELFAttributes.[cpp|h]. Differential Revision: https://reviews.llvm.org/D74023
2020-02-04 22:20:10 +08:00
Attr = Attributes.getAttributeValue(ARMBuildAttrs::THUMB_ISA_use);
if (Attr.hasValue()) {
switch (Attr.getValue()) {
[ARM] Create SubtargetFeatures from build attrs An ELFObjectFile can now create SubtargetFeatures from the available ARM build attributes, in a similar manner to MIPS. I've moved the MIPS code into its own function and the ARM handler also has a separate function. Differential Revision: https://reviews.llvm.org/D28291 llvm-svn: 292403
2017-01-18 23:52:11 +08:00
default:
[llvm-objdump] Support detection of feature bits from the object and implement this for Mips. Summary: The Mips implementation only covers the feature bits described by the ELF e_flags so far. Mips stores additional feature bits such as MSA in the .MIPS.abiflags section. Also fixed a small bug this revealed where microMIPS wouldn't add the EF_MIPS_MICROMIPS flag when using -filetype=obj. Reviewers: echristo, rafael Subscribers: rafael, mehdi_amini, dsanders, sdardis, llvm-commits Differential Revision: http://reviews.llvm.org/D21125 llvm-svn: 272880
2016-06-16 17:17:03 +08:00
break;
[ARM] Create SubtargetFeatures from build attrs An ELFObjectFile can now create SubtargetFeatures from the available ARM build attributes, in a similar manner to MIPS. I've moved the MIPS code into its own function and the ARM handler also has a separate function. Differential Revision: https://reviews.llvm.org/D28291 llvm-svn: 292403
2017-01-18 23:52:11 +08:00
case ARMBuildAttrs::Not_Allowed:
Features.AddFeature("thumb", false);
Features.AddFeature("thumb2", false);
[llvm-objdump] Support detection of feature bits from the object and implement this for Mips. Summary: The Mips implementation only covers the feature bits described by the ELF e_flags so far. Mips stores additional feature bits such as MSA in the .MIPS.abiflags section. Also fixed a small bug this revealed where microMIPS wouldn't add the EF_MIPS_MICROMIPS flag when using -filetype=obj. Reviewers: echristo, rafael Subscribers: rafael, mehdi_amini, dsanders, sdardis, llvm-commits Differential Revision: http://reviews.llvm.org/D21125 llvm-svn: 272880
2016-06-16 17:17:03 +08:00
break;
[ARM] Create SubtargetFeatures from build attrs An ELFObjectFile can now create SubtargetFeatures from the available ARM build attributes, in a similar manner to MIPS. I've moved the MIPS code into its own function and the ARM handler also has a separate function. Differential Revision: https://reviews.llvm.org/D28291 llvm-svn: 292403
2017-01-18 23:52:11 +08:00
case ARMBuildAttrs::AllowThumb32:
Features.AddFeature("thumb2");
[llvm-objdump] Support detection of feature bits from the object and implement this for Mips. Summary: The Mips implementation only covers the feature bits described by the ELF e_flags so far. Mips stores additional feature bits such as MSA in the .MIPS.abiflags section. Also fixed a small bug this revealed where microMIPS wouldn't add the EF_MIPS_MICROMIPS flag when using -filetype=obj. Reviewers: echristo, rafael Subscribers: rafael, mehdi_amini, dsanders, sdardis, llvm-commits Differential Revision: http://reviews.llvm.org/D21125 llvm-svn: 272880
2016-06-16 17:17:03 +08:00
break;
[ARM] Create SubtargetFeatures from build attrs An ELFObjectFile can now create SubtargetFeatures from the available ARM build attributes, in a similar manner to MIPS. I've moved the MIPS code into its own function and the ARM handler also has a separate function. Differential Revision: https://reviews.llvm.org/D28291 llvm-svn: 292403
2017-01-18 23:52:11 +08:00
}
}
[RISCV] ELF attribute section for RISC-V. Leverage ARM ELF build attribute section to create ELF attribute section for RISC-V. Extract the common part of parsing logic for this section into ELFAttributeParser.[cpp|h] and ELFAttributes.[cpp|h]. Differential Revision: https://reviews.llvm.org/D74023
2020-02-04 22:20:10 +08:00
Attr = Attributes.getAttributeValue(ARMBuildAttrs::FP_arch);
if (Attr.hasValue()) {
switch (Attr.getValue()) {
[ARM] Create SubtargetFeatures from build attrs An ELFObjectFile can now create SubtargetFeatures from the available ARM build attributes, in a similar manner to MIPS. I've moved the MIPS code into its own function and the ARM handler also has a separate function. Differential Revision: https://reviews.llvm.org/D28291 llvm-svn: 292403
2017-01-18 23:52:11 +08:00
default:
[llvm-objdump] Support detection of feature bits from the object and implement this for Mips. Summary: The Mips implementation only covers the feature bits described by the ELF e_flags so far. Mips stores additional feature bits such as MSA in the .MIPS.abiflags section. Also fixed a small bug this revealed where microMIPS wouldn't add the EF_MIPS_MICROMIPS flag when using -filetype=obj. Reviewers: echristo, rafael Subscribers: rafael, mehdi_amini, dsanders, sdardis, llvm-commits Differential Revision: http://reviews.llvm.org/D21125 llvm-svn: 272880
2016-06-16 17:17:03 +08:00
break;
[ARM] Create SubtargetFeatures from build attrs An ELFObjectFile can now create SubtargetFeatures from the available ARM build attributes, in a similar manner to MIPS. I've moved the MIPS code into its own function and the ARM handler also has a separate function. Differential Revision: https://reviews.llvm.org/D28291 llvm-svn: 292403
2017-01-18 23:52:11 +08:00
case ARMBuildAttrs::Not_Allowed:
[ARM] VFPv2 only supports 16 D registers. r361845 changed the way we handle "D16" vs. "D32" targets; there used to be a negative "d16" which removed instructions from the instruction set, and now there's a "d32" feature which adds instructions to the instruction set. This is good, but there was an oversight in the implementation: the behavior of VFPv2 was changed. In particular, the "vfp2" feature was changed to imply "d32". This is wrong: VFPv2 only supports 16 D registers. In practice, this means if you specify -mfpu=vfpv2, the compiler will generate illegal instructions. This patch gets rid of "vfp2d16" and "vfp2d16sp", and fixes "vfp2" and "vfp2sp" so they don't imply "d32". Differential Revision: https://reviews.llvm.org/D67375 llvm-svn: 372186
2019-09-18 05:42:38 +08:00
Features.AddFeature("vfp2sp", false);
[ARM] Replace fp-only-sp and d16 with fp64 and d32. Those two subtarget features were awkward because their semantics are reversed: each one indicates the _lack_ of support for something in the architecture, rather than the presence. As a consequence, you don't get the behavior you want if you combine two sets of feature bits. Each SubtargetFeature for an FP architecture version now comes in four versions, one for each combination of those options. So you can still say (for example) '+vfp2' in a feature string and it will mean what it's always meant, but there's a new string '+vfp2d16sp' meaning the version without those extra options. A lot of this change is just mechanically replacing positive checks for the old features with negative checks for the new ones. But one more interesting change is that I've rearranged getFPUFeatures() so that the main FPU feature is appended to the output list *before* rather than after the features derived from the Restriction field, so that -fp64 and -d32 can override defaults added by the main feature. Reviewers: dmgreen, samparker, SjoerdMeijer Subscribers: srhines, javed.absar, eraman, kristof.beyls, hiraditya, zzheng, Petar.Avramovic, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D60691 llvm-svn: 361845
2019-05-29 00:13:20 +08:00
Features.AddFeature("vfp3d16sp", false);
Features.AddFeature("vfp4d16sp", false);
[llvm-objdump] Support detection of feature bits from the object and implement this for Mips. Summary: The Mips implementation only covers the feature bits described by the ELF e_flags so far. Mips stores additional feature bits such as MSA in the .MIPS.abiflags section. Also fixed a small bug this revealed where microMIPS wouldn't add the EF_MIPS_MICROMIPS flag when using -filetype=obj. Reviewers: echristo, rafael Subscribers: rafael, mehdi_amini, dsanders, sdardis, llvm-commits Differential Revision: http://reviews.llvm.org/D21125 llvm-svn: 272880
2016-06-16 17:17:03 +08:00
break;
[ARM] Create SubtargetFeatures from build attrs An ELFObjectFile can now create SubtargetFeatures from the available ARM build attributes, in a similar manner to MIPS. I've moved the MIPS code into its own function and the ARM handler also has a separate function. Differential Revision: https://reviews.llvm.org/D28291 llvm-svn: 292403
2017-01-18 23:52:11 +08:00
case ARMBuildAttrs::AllowFPv2:
Features.AddFeature("vfp2");
[llvm-objdump] Support detection of feature bits from the object and implement this for Mips. Summary: The Mips implementation only covers the feature bits described by the ELF e_flags so far. Mips stores additional feature bits such as MSA in the .MIPS.abiflags section. Also fixed a small bug this revealed where microMIPS wouldn't add the EF_MIPS_MICROMIPS flag when using -filetype=obj. Reviewers: echristo, rafael Subscribers: rafael, mehdi_amini, dsanders, sdardis, llvm-commits Differential Revision: http://reviews.llvm.org/D21125 llvm-svn: 272880
2016-06-16 17:17:03 +08:00
break;
[ARM] Create SubtargetFeatures from build attrs An ELFObjectFile can now create SubtargetFeatures from the available ARM build attributes, in a similar manner to MIPS. I've moved the MIPS code into its own function and the ARM handler also has a separate function. Differential Revision: https://reviews.llvm.org/D28291 llvm-svn: 292403
2017-01-18 23:52:11 +08:00
case ARMBuildAttrs::AllowFPv3A:
case ARMBuildAttrs::AllowFPv3B:
Features.AddFeature("vfp3");
[llvm-objdump] Support detection of feature bits from the object and implement this for Mips. Summary: The Mips implementation only covers the feature bits described by the ELF e_flags so far. Mips stores additional feature bits such as MSA in the .MIPS.abiflags section. Also fixed a small bug this revealed where microMIPS wouldn't add the EF_MIPS_MICROMIPS flag when using -filetype=obj. Reviewers: echristo, rafael Subscribers: rafael, mehdi_amini, dsanders, sdardis, llvm-commits Differential Revision: http://reviews.llvm.org/D21125 llvm-svn: 272880
2016-06-16 17:17:03 +08:00
break;
[ARM] Create SubtargetFeatures from build attrs An ELFObjectFile can now create SubtargetFeatures from the available ARM build attributes, in a similar manner to MIPS. I've moved the MIPS code into its own function and the ARM handler also has a separate function. Differential Revision: https://reviews.llvm.org/D28291 llvm-svn: 292403
2017-01-18 23:52:11 +08:00
case ARMBuildAttrs::AllowFPv4A:
case ARMBuildAttrs::AllowFPv4B:
Features.AddFeature("vfp4");
[llvm-objdump] Support detection of feature bits from the object and implement this for Mips. Summary: The Mips implementation only covers the feature bits described by the ELF e_flags so far. Mips stores additional feature bits such as MSA in the .MIPS.abiflags section. Also fixed a small bug this revealed where microMIPS wouldn't add the EF_MIPS_MICROMIPS flag when using -filetype=obj. Reviewers: echristo, rafael Subscribers: rafael, mehdi_amini, dsanders, sdardis, llvm-commits Differential Revision: http://reviews.llvm.org/D21125 llvm-svn: 272880
2016-06-16 17:17:03 +08:00
break;
}
[ARM] Create SubtargetFeatures from build attrs An ELFObjectFile can now create SubtargetFeatures from the available ARM build attributes, in a similar manner to MIPS. I've moved the MIPS code into its own function and the ARM handler also has a separate function. Differential Revision: https://reviews.llvm.org/D28291 llvm-svn: 292403
2017-01-18 23:52:11 +08:00
}
[llvm-objdump] Support detection of feature bits from the object and implement this for Mips. Summary: The Mips implementation only covers the feature bits described by the ELF e_flags so far. Mips stores additional feature bits such as MSA in the .MIPS.abiflags section. Also fixed a small bug this revealed where microMIPS wouldn't add the EF_MIPS_MICROMIPS flag when using -filetype=obj. Reviewers: echristo, rafael Subscribers: rafael, mehdi_amini, dsanders, sdardis, llvm-commits Differential Revision: http://reviews.llvm.org/D21125 llvm-svn: 272880
2016-06-16 17:17:03 +08:00
[RISCV] ELF attribute section for RISC-V. Leverage ARM ELF build attribute section to create ELF attribute section for RISC-V. Extract the common part of parsing logic for this section into ELFAttributeParser.[cpp|h] and ELFAttributes.[cpp|h]. Differential Revision: https://reviews.llvm.org/D74023
2020-02-04 22:20:10 +08:00
Attr = Attributes.getAttributeValue(ARMBuildAttrs::Advanced_SIMD_arch);
if (Attr.hasValue()) {
switch (Attr.getValue()) {
[ARM] Create SubtargetFeatures from build attrs An ELFObjectFile can now create SubtargetFeatures from the available ARM build attributes, in a similar manner to MIPS. I've moved the MIPS code into its own function and the ARM handler also has a separate function. Differential Revision: https://reviews.llvm.org/D28291 llvm-svn: 292403
2017-01-18 23:52:11 +08:00
default:
break;
case ARMBuildAttrs::Not_Allowed:
Features.AddFeature("neon", false);
Features.AddFeature("fp16", false);
[llvm-objdump] Support detection of feature bits from the object and implement this for Mips. Summary: The Mips implementation only covers the feature bits described by the ELF e_flags so far. Mips stores additional feature bits such as MSA in the .MIPS.abiflags section. Also fixed a small bug this revealed where microMIPS wouldn't add the EF_MIPS_MICROMIPS flag when using -filetype=obj. Reviewers: echristo, rafael Subscribers: rafael, mehdi_amini, dsanders, sdardis, llvm-commits Differential Revision: http://reviews.llvm.org/D21125 llvm-svn: 272880
2016-06-16 17:17:03 +08:00
break;
[ARM] Create SubtargetFeatures from build attrs An ELFObjectFile can now create SubtargetFeatures from the available ARM build attributes, in a similar manner to MIPS. I've moved the MIPS code into its own function and the ARM handler also has a separate function. Differential Revision: https://reviews.llvm.org/D28291 llvm-svn: 292403
2017-01-18 23:52:11 +08:00
case ARMBuildAttrs::AllowNeon:
Features.AddFeature("neon");
[llvm-objdump] Support detection of feature bits from the object and implement this for Mips. Summary: The Mips implementation only covers the feature bits described by the ELF e_flags so far. Mips stores additional feature bits such as MSA in the .MIPS.abiflags section. Also fixed a small bug this revealed where microMIPS wouldn't add the EF_MIPS_MICROMIPS flag when using -filetype=obj. Reviewers: echristo, rafael Subscribers: rafael, mehdi_amini, dsanders, sdardis, llvm-commits Differential Revision: http://reviews.llvm.org/D21125 llvm-svn: 272880
2016-06-16 17:17:03 +08:00
break;
[ARM] Create SubtargetFeatures from build attrs An ELFObjectFile can now create SubtargetFeatures from the available ARM build attributes, in a similar manner to MIPS. I've moved the MIPS code into its own function and the ARM handler also has a separate function. Differential Revision: https://reviews.llvm.org/D28291 llvm-svn: 292403
2017-01-18 23:52:11 +08:00
case ARMBuildAttrs::AllowNeon2:
Features.AddFeature("neon");
Features.AddFeature("fp16");
break;
}
}
[RISCV] ELF attribute section for RISC-V. Leverage ARM ELF build attribute section to create ELF attribute section for RISC-V. Extract the common part of parsing logic for this section into ELFAttributeParser.[cpp|h] and ELFAttributes.[cpp|h]. Differential Revision: https://reviews.llvm.org/D74023
2020-02-04 22:20:10 +08:00
Attr = Attributes.getAttributeValue(ARMBuildAttrs::MVE_arch);
if (Attr.hasValue()) {
switch (Attr.getValue()) {
[ARM] add target arch definitions for 8.1-M and MVE This adds: - LLVM subtarget features to make all the new instructions conditional on, - CPU and FPU names for use on clang's command line, with default FPUs set so that "armv8.1-m.main+fp" and "armv8.1-m.main+fp.dp" will select the right FPU features, - architecture extension names "mve" and "mve.fp", - ABI build attribute support for v8.1-M (a new value for Tag_CPU_arch) and MVE (a new actual tag). Patch mostly by Simon Tatham. Differential Revision: https://reviews.llvm.org/D60698 llvm-svn: 362090
2019-05-30 20:57:04 +08:00
default:
break;
case ARMBuildAttrs::Not_Allowed:
Features.AddFeature("mve", false);
Features.AddFeature("mve.fp", false);
break;
case ARMBuildAttrs::AllowMVEInteger:
Features.AddFeature("mve.fp", false);
Features.AddFeature("mve");
break;
case ARMBuildAttrs::AllowMVEIntegerAndFloat:
Features.AddFeature("mve.fp");
break;
}
}
[RISCV] ELF attribute section for RISC-V. Leverage ARM ELF build attribute section to create ELF attribute section for RISC-V. Extract the common part of parsing logic for this section into ELFAttributeParser.[cpp|h] and ELFAttributes.[cpp|h]. Differential Revision: https://reviews.llvm.org/D74023
2020-02-04 22:20:10 +08:00
Attr = Attributes.getAttributeValue(ARMBuildAttrs::DIV_use);
if (Attr.hasValue()) {
switch (Attr.getValue()) {
[llvm-objdump] Support detection of feature bits from the object and implement this for Mips. Summary: The Mips implementation only covers the feature bits described by the ELF e_flags so far. Mips stores additional feature bits such as MSA in the .MIPS.abiflags section. Also fixed a small bug this revealed where microMIPS wouldn't add the EF_MIPS_MICROMIPS flag when using -filetype=obj. Reviewers: echristo, rafael Subscribers: rafael, mehdi_amini, dsanders, sdardis, llvm-commits Differential Revision: http://reviews.llvm.org/D21125 llvm-svn: 272880
2016-06-16 17:17:03 +08:00
default:
[ARM] Create SubtargetFeatures from build attrs An ELFObjectFile can now create SubtargetFeatures from the available ARM build attributes, in a similar manner to MIPS. I've moved the MIPS code into its own function and the ARM handler also has a separate function. Differential Revision: https://reviews.llvm.org/D28291 llvm-svn: 292403
2017-01-18 23:52:11 +08:00
break;
case ARMBuildAttrs::DisallowDIV:
Features.AddFeature("hwdiv", false);
Features.AddFeature("hwdiv-arm", false);
break;
case ARMBuildAttrs::AllowDIVExt:
Features.AddFeature("hwdiv");
Features.AddFeature("hwdiv-arm");
break;
[llvm-objdump] Support detection of feature bits from the object and implement this for Mips. Summary: The Mips implementation only covers the feature bits described by the ELF e_flags so far. Mips stores additional feature bits such as MSA in the .MIPS.abiflags section. Also fixed a small bug this revealed where microMIPS wouldn't add the EF_MIPS_MICROMIPS flag when using -filetype=obj. Reviewers: echristo, rafael Subscribers: rafael, mehdi_amini, dsanders, sdardis, llvm-commits Differential Revision: http://reviews.llvm.org/D21125 llvm-svn: 272880
2016-06-16 17:17:03 +08:00
}
[ARM] Create SubtargetFeatures from build attrs An ELFObjectFile can now create SubtargetFeatures from the available ARM build attributes, in a similar manner to MIPS. I've moved the MIPS code into its own function and the ARM handler also has a separate function. Differential Revision: https://reviews.llvm.org/D28291 llvm-svn: 292403
2017-01-18 23:52:11 +08:00
}
[llvm-objdump] Support detection of feature bits from the object and implement this for Mips. Summary: The Mips implementation only covers the feature bits described by the ELF e_flags so far. Mips stores additional feature bits such as MSA in the .MIPS.abiflags section. Also fixed a small bug this revealed where microMIPS wouldn't add the EF_MIPS_MICROMIPS flag when using -filetype=obj. Reviewers: echristo, rafael Subscribers: rafael, mehdi_amini, dsanders, sdardis, llvm-commits Differential Revision: http://reviews.llvm.org/D21125 llvm-svn: 272880
2016-06-16 17:17:03 +08:00
[ARM] Create SubtargetFeatures from build attrs An ELFObjectFile can now create SubtargetFeatures from the available ARM build attributes, in a similar manner to MIPS. I've moved the MIPS code into its own function and the ARM handler also has a separate function. Differential Revision: https://reviews.llvm.org/D28291 llvm-svn: 292403
2017-01-18 23:52:11 +08:00
return Features;
}
[llvm-objdump] Support detection of feature bits from the object and implement this for Mips. Summary: The Mips implementation only covers the feature bits described by the ELF e_flags so far. Mips stores additional feature bits such as MSA in the .MIPS.abiflags section. Also fixed a small bug this revealed where microMIPS wouldn't add the EF_MIPS_MICROMIPS flag when using -filetype=obj. Reviewers: echristo, rafael Subscribers: rafael, mehdi_amini, dsanders, sdardis, llvm-commits Differential Revision: http://reviews.llvm.org/D21125 llvm-svn: 272880
2016-06-16 17:17:03 +08:00
[RISCV] Add ELFObjectFileBase::getRISCVFeatures let llvm-objdump could get RISCV target feature llvm-objdump could get C feature by ELF::EF_RISCV_RVC e_flag, so then we don't have to add -mattr=+c on the command line. Differential Revision: https://reviews.llvm.org/D42629 llvm-svn: 324058
2018-02-02 14:01:02 +08:00
SubtargetFeatures ELFObjectFileBase::getRISCVFeatures() const {
SubtargetFeatures Features;
unsigned PlatformFlags = getPlatformFlags();
if (PlatformFlags & ELF::EF_RISCV_RVC) {
Features.AddFeature("c");
}
[RISCV] ELF attribute section for RISC-V. Leverage ARM ELF build attribute section to create ELF attribute section for RISC-V. Extract the common part of parsing logic for this section into ELFAttributeParser.[cpp|h] and ELFAttributes.[cpp|h]. Differential Revision: https://reviews.llvm.org/D74023
2020-02-04 22:20:10 +08:00
// Add features according to the ELF attribute section.
// If there are any unrecognized features, ignore them.
RISCVAttributeParser Attributes;
[RISCV] Consume error from parsing attributes section Summary: We don't consume the error from getBuildAttributes, so an assertions build crashes with "Program aborted due to an unhandled Error:". Explicitly consume it like the ARM version in that case. Reviewers: asb, jhenderson, MaskRay, HsiangKai Reviewed By: MaskRay Subscribers: kristof.beyls, hiraditya, simoncook, kito-cheng, shiva0217, rogfer01, rkruppe, psnobl, benna, Jim, lenary, s.egerton, sameer.abuasal, luismarques, evandro, danielkiss, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D77841
2020-04-10 08:30:48 +08:00
if (Error E = getBuildAttributes(Attributes)) {
// TODO Propagate Error.
consumeError(std::move(E));
[RISCV] ELF attribute section for RISC-V. Leverage ARM ELF build attribute section to create ELF attribute section for RISC-V. Extract the common part of parsing logic for this section into ELFAttributeParser.[cpp|h] and ELFAttributes.[cpp|h]. Differential Revision: https://reviews.llvm.org/D74023
2020-02-04 22:20:10 +08:00
return Features; // Keep "c" feature if there is one in PlatformFlags.
[RISCV] Consume error from parsing attributes section Summary: We don't consume the error from getBuildAttributes, so an assertions build crashes with "Program aborted due to an unhandled Error:". Explicitly consume it like the ARM version in that case. Reviewers: asb, jhenderson, MaskRay, HsiangKai Reviewed By: MaskRay Subscribers: kristof.beyls, hiraditya, simoncook, kito-cheng, shiva0217, rogfer01, rkruppe, psnobl, benna, Jim, lenary, s.egerton, sameer.abuasal, luismarques, evandro, danielkiss, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D77841
2020-04-10 08:30:48 +08:00
}
[RISCV] ELF attribute section for RISC-V. Leverage ARM ELF build attribute section to create ELF attribute section for RISC-V. Extract the common part of parsing logic for this section into ELFAttributeParser.[cpp|h] and ELFAttributes.[cpp|h]. Differential Revision: https://reviews.llvm.org/D74023
2020-02-04 22:20:10 +08:00
Optional<StringRef> Attr = Attributes.getAttributeString(RISCVAttrs::ARCH);
if (Attr.hasValue()) {
// The Arch pattern is [rv32|rv64][i|e]version(_[m|a|f|d|c]version)*
// Version string pattern is (major)p(minor). Major and minor are optional.
// For example, a version number could be 2p0, 2, or p92.
StringRef Arch = Attr.getValue();
if (Arch.consume_front("rv32"))
Features.AddFeature("64bit", false);
else if (Arch.consume_front("rv64"))
Features.AddFeature("64bit");
while (!Arch.empty()) {
switch (Arch[0]) {
default:
break; // Ignore unexpected features.
case 'i':
Features.AddFeature("e", false);
break;
case 'd':
Features.AddFeature("f"); // D-ext will imply F-ext.
LLVM_FALLTHROUGH;
case 'e':
case 'm':
case 'a':
case 'f':
case 'c':
Features.AddFeature(Arch.take_front());
break;
}
// FIXME: Handle version numbers.
Arch = Arch.drop_until([](char c) { return c == '_' || c == '\0'; });
Arch = Arch.drop_while([](char c) { return c == '_'; });
}
}
[RISCV] Add ELFObjectFileBase::getRISCVFeatures let llvm-objdump could get RISCV target feature llvm-objdump could get C feature by ELF::EF_RISCV_RVC e_flag, so then we don't have to add -mattr=+c on the command line. Differential Revision: https://reviews.llvm.org/D42629 llvm-svn: 324058
2018-02-02 14:01:02 +08:00
return Features;
}
[ARM] Create SubtargetFeatures from build attrs An ELFObjectFile can now create SubtargetFeatures from the available ARM build attributes, in a similar manner to MIPS. I've moved the MIPS code into its own function and the ARM handler also has a separate function. Differential Revision: https://reviews.llvm.org/D28291 llvm-svn: 292403
2017-01-18 23:52:11 +08:00
SubtargetFeatures ELFObjectFileBase::getFeatures() const {
switch (getEMachine()) {
case ELF::EM_MIPS:
return getMIPSFeatures();
case ELF::EM_ARM:
return getARMFeatures();
[RISCV] Add ELFObjectFileBase::getRISCVFeatures let llvm-objdump could get RISCV target feature llvm-objdump could get C feature by ELF::EF_RISCV_RVC e_flag, so then we don't have to add -mattr=+c on the command line. Differential Revision: https://reviews.llvm.org/D42629 llvm-svn: 324058
2018-02-02 14:01:02 +08:00
case ELF::EM_RISCV:
return getRISCVFeatures();
[llvm-objdump] Support detection of feature bits from the object and implement this for Mips. Summary: The Mips implementation only covers the feature bits described by the ELF e_flags so far. Mips stores additional feature bits such as MSA in the .MIPS.abiflags section. Also fixed a small bug this revealed where microMIPS wouldn't add the EF_MIPS_MICROMIPS flag when using -filetype=obj. Reviewers: echristo, rafael Subscribers: rafael, mehdi_amini, dsanders, sdardis, llvm-commits Differential Revision: http://reviews.llvm.org/D21125 llvm-svn: 272880
2016-06-16 17:17:03 +08:00
default:
return SubtargetFeatures();
}
}
[llvm-objdump][AMDGPU] Detect CPU string AMDGPU ISA isn't backwards compatible and hence -mcpu must always be specified during disassembly. However, the AMDGPU target CPU is stored in e_flags in the ELF object. This patch allows targets to implement CPU string detection, and also implements it for AMDGPU by looking at e_flags. Reviewed By: scott.linder Differential Revision: https://reviews.llvm.org/D84519
2020-07-24 17:51:46 +08:00
Optional<StringRef> ELFObjectFileBase::tryGetCPUName() const {
switch (getEMachine()) {
case ELF::EM_AMDGPU:
return getAMDGPUCPUName();
default:
return None;
}
}
StringRef ELFObjectFileBase::getAMDGPUCPUName() const {
assert(getEMachine() == ELF::EM_AMDGPU);
unsigned CPU = getPlatformFlags() & ELF::EF_AMDGPU_MACH;
switch (CPU) {
// Radeon HD 2000/3000 Series (R600).
case ELF::EF_AMDGPU_MACH_R600_R600:
return "r600";
case ELF::EF_AMDGPU_MACH_R600_R630:
return "r630";
case ELF::EF_AMDGPU_MACH_R600_RS880:
return "rs880";
case ELF::EF_AMDGPU_MACH_R600_RV670:
return "rv670";
// Radeon HD 4000 Series (R700).
case ELF::EF_AMDGPU_MACH_R600_RV710:
return "rv710";
case ELF::EF_AMDGPU_MACH_R600_RV730:
return "rv730";
case ELF::EF_AMDGPU_MACH_R600_RV770:
return "rv770";
// Radeon HD 5000 Series (Evergreen).
case ELF::EF_AMDGPU_MACH_R600_CEDAR:
return "cedar";
case ELF::EF_AMDGPU_MACH_R600_CYPRESS:
return "cypress";
case ELF::EF_AMDGPU_MACH_R600_JUNIPER:
return "juniper";
case ELF::EF_AMDGPU_MACH_R600_REDWOOD:
return "redwood";
case ELF::EF_AMDGPU_MACH_R600_SUMO:
return "sumo";
// Radeon HD 6000 Series (Northern Islands).
case ELF::EF_AMDGPU_MACH_R600_BARTS:
return "barts";
case ELF::EF_AMDGPU_MACH_R600_CAICOS:
return "caicos";
case ELF::EF_AMDGPU_MACH_R600_CAYMAN:
return "cayman";
case ELF::EF_AMDGPU_MACH_R600_TURKS:
return "turks";
// AMDGCN GFX6.
case ELF::EF_AMDGPU_MACH_AMDGCN_GFX600:
return "gfx600";
case ELF::EF_AMDGPU_MACH_AMDGCN_GFX601:
return "gfx601";
[AMDGPU] Add gfx602, gfx705, gfx805 targets At AMD, in an internal audit of our code, we found some corner cases where we were not quite differentiating targets enough for some old hardware. This commit is part of fixing that by adding three new targets: * The "Oland" and "Hainan" variants of gfx601 are now split out into gfx602. LLPC (in the GPUOpen driver) and other front-ends could use that to avoid using the shaderZExport workaround on gfx602. * One variant of gfx703 is now split out into gfx705. LLPC and other front-ends could use that to avoid using the shaderSpiCsRegAllocFragmentation workaround on gfx705. * The "TongaPro" variant of gfx802 is now split out into gfx805. TongaPro has a faster 64-bit shift than its former friends in gfx802, and a subtarget feature could be set up for that to take advantage of it. This commit does not make that change; it just adds the target. V2: Add clang changes. Put TargetParser list in order. V3: AMDGCNGPUs table in TargetParser.cpp needs to be in GPUKind order, so fix the GPUKind order. Differential Revision: https://reviews.llvm.org/D88916 Change-Id: Ia901a7157eb2f73ccd9f25dbacec38427312377d
2020-10-07 01:23:59 +08:00
case ELF::EF_AMDGPU_MACH_AMDGCN_GFX602:
return "gfx602";
[llvm-objdump][AMDGPU] Detect CPU string AMDGPU ISA isn't backwards compatible and hence -mcpu must always be specified during disassembly. However, the AMDGPU target CPU is stored in e_flags in the ELF object. This patch allows targets to implement CPU string detection, and also implements it for AMDGPU by looking at e_flags. Reviewed By: scott.linder Differential Revision: https://reviews.llvm.org/D84519
2020-07-24 17:51:46 +08:00
// AMDGCN GFX7.
case ELF::EF_AMDGPU_MACH_AMDGCN_GFX700:
return "gfx700";
case ELF::EF_AMDGPU_MACH_AMDGCN_GFX701:
return "gfx701";
case ELF::EF_AMDGPU_MACH_AMDGCN_GFX702:
return "gfx702";
case ELF::EF_AMDGPU_MACH_AMDGCN_GFX703:
return "gfx703";
case ELF::EF_AMDGPU_MACH_AMDGCN_GFX704:
return "gfx704";
[AMDGPU] Add gfx602, gfx705, gfx805 targets At AMD, in an internal audit of our code, we found some corner cases where we were not quite differentiating targets enough for some old hardware. This commit is part of fixing that by adding three new targets: * The "Oland" and "Hainan" variants of gfx601 are now split out into gfx602. LLPC (in the GPUOpen driver) and other front-ends could use that to avoid using the shaderZExport workaround on gfx602. * One variant of gfx703 is now split out into gfx705. LLPC and other front-ends could use that to avoid using the shaderSpiCsRegAllocFragmentation workaround on gfx705. * The "TongaPro" variant of gfx802 is now split out into gfx805. TongaPro has a faster 64-bit shift than its former friends in gfx802, and a subtarget feature could be set up for that to take advantage of it. This commit does not make that change; it just adds the target. V2: Add clang changes. Put TargetParser list in order. V3: AMDGCNGPUs table in TargetParser.cpp needs to be in GPUKind order, so fix the GPUKind order. Differential Revision: https://reviews.llvm.org/D88916 Change-Id: Ia901a7157eb2f73ccd9f25dbacec38427312377d
2020-10-07 01:23:59 +08:00
case ELF::EF_AMDGPU_MACH_AMDGCN_GFX705:
return "gfx705";
[llvm-objdump][AMDGPU] Detect CPU string AMDGPU ISA isn't backwards compatible and hence -mcpu must always be specified during disassembly. However, the AMDGPU target CPU is stored in e_flags in the ELF object. This patch allows targets to implement CPU string detection, and also implements it for AMDGPU by looking at e_flags. Reviewed By: scott.linder Differential Revision: https://reviews.llvm.org/D84519
2020-07-24 17:51:46 +08:00
// AMDGCN GFX8.
case ELF::EF_AMDGPU_MACH_AMDGCN_GFX801:
return "gfx801";
case ELF::EF_AMDGPU_MACH_AMDGCN_GFX802:
return "gfx802";
case ELF::EF_AMDGPU_MACH_AMDGCN_GFX803:
return "gfx803";
[AMDGPU] Add gfx602, gfx705, gfx805 targets At AMD, in an internal audit of our code, we found some corner cases where we were not quite differentiating targets enough for some old hardware. This commit is part of fixing that by adding three new targets: * The "Oland" and "Hainan" variants of gfx601 are now split out into gfx602. LLPC (in the GPUOpen driver) and other front-ends could use that to avoid using the shaderZExport workaround on gfx602. * One variant of gfx703 is now split out into gfx705. LLPC and other front-ends could use that to avoid using the shaderSpiCsRegAllocFragmentation workaround on gfx705. * The "TongaPro" variant of gfx802 is now split out into gfx805. TongaPro has a faster 64-bit shift than its former friends in gfx802, and a subtarget feature could be set up for that to take advantage of it. This commit does not make that change; it just adds the target. V2: Add clang changes. Put TargetParser list in order. V3: AMDGCNGPUs table in TargetParser.cpp needs to be in GPUKind order, so fix the GPUKind order. Differential Revision: https://reviews.llvm.org/D88916 Change-Id: Ia901a7157eb2f73ccd9f25dbacec38427312377d
2020-10-07 01:23:59 +08:00
case ELF::EF_AMDGPU_MACH_AMDGCN_GFX805:
return "gfx805";
[llvm-objdump][AMDGPU] Detect CPU string AMDGPU ISA isn't backwards compatible and hence -mcpu must always be specified during disassembly. However, the AMDGPU target CPU is stored in e_flags in the ELF object. This patch allows targets to implement CPU string detection, and also implements it for AMDGPU by looking at e_flags. Reviewed By: scott.linder Differential Revision: https://reviews.llvm.org/D84519
2020-07-24 17:51:46 +08:00
case ELF::EF_AMDGPU_MACH_AMDGCN_GFX810:
return "gfx810";
// AMDGCN GFX9.
case ELF::EF_AMDGPU_MACH_AMDGCN_GFX900:
return "gfx900";
case ELF::EF_AMDGPU_MACH_AMDGCN_GFX902:
return "gfx902";
case ELF::EF_AMDGPU_MACH_AMDGCN_GFX904:
return "gfx904";
case ELF::EF_AMDGPU_MACH_AMDGCN_GFX906:
return "gfx906";
case ELF::EF_AMDGPU_MACH_AMDGCN_GFX908:
return "gfx908";
case ELF::EF_AMDGPU_MACH_AMDGCN_GFX909:
return "gfx909";
[AMDGPU] gfx90a support Differential Revision: https://reviews.llvm.org/D96906
2021-02-18 05:37:46 +08:00
case ELF::EF_AMDGPU_MACH_AMDGCN_GFX90A:
return "gfx90a";
[AMDGPU] Add gfx90c target This differentiates the Ryzen 4000/4300/4500/4700 series APUs that were previously included in gfx909. Differential Revision: https://reviews.llvm.org/D90419 Change-Id: Ia901a7157eb2f73ccd9f25dbacec38427312377d
2020-10-07 01:23:59 +08:00
case ELF::EF_AMDGPU_MACH_AMDGCN_GFX90C:
return "gfx90c";
[llvm-objdump][AMDGPU] Detect CPU string AMDGPU ISA isn't backwards compatible and hence -mcpu must always be specified during disassembly. However, the AMDGPU target CPU is stored in e_flags in the ELF object. This patch allows targets to implement CPU string detection, and also implements it for AMDGPU by looking at e_flags. Reviewed By: scott.linder Differential Revision: https://reviews.llvm.org/D84519
2020-07-24 17:51:46 +08:00
// AMDGCN GFX10.
case ELF::EF_AMDGPU_MACH_AMDGCN_GFX1010:
return "gfx1010";
case ELF::EF_AMDGPU_MACH_AMDGCN_GFX1011:
return "gfx1011";
case ELF::EF_AMDGPU_MACH_AMDGCN_GFX1012:
return "gfx1012";
Reland "[AMDGPU] Add gfx1013 target" This reverts commit 211e584fa2a4c032e4d573e7cdbffd622aad0a8f. Fixed a use-after-free error that caused the sanitizers to fail.
2021-06-09 04:54:42 +08:00
case ELF::EF_AMDGPU_MACH_AMDGCN_GFX1013:
return "gfx1013";
[llvm-objdump][AMDGPU] Detect CPU string AMDGPU ISA isn't backwards compatible and hence -mcpu must always be specified during disassembly. However, the AMDGPU target CPU is stored in e_flags in the ELF object. This patch allows targets to implement CPU string detection, and also implements it for AMDGPU by looking at e_flags. Reviewed By: scott.linder Differential Revision: https://reviews.llvm.org/D84519
2020-07-24 17:51:46 +08:00
case ELF::EF_AMDGPU_MACH_AMDGCN_GFX1030:
return "gfx1030";
[AMDGPU] Add missing support for targets - Add missing tests. Differential Revision: https://reviews.llvm.org/D90212
2020-10-26 09:16:59 +08:00
case ELF::EF_AMDGPU_MACH_AMDGCN_GFX1031:
return "gfx1031";
case ELF::EF_AMDGPU_MACH_AMDGCN_GFX1032:
return "gfx1032";
[AMDGPU] Add gfx1033 target Differential Revision: https://reviews.llvm.org/D90447 Change-Id: If2650fc7f31bbdd49c76e74a9ca8e3734d769761
2020-10-30 16:21:12 +08:00
case ELF::EF_AMDGPU_MACH_AMDGCN_GFX1033:
return "gfx1033";
[AMDGPU] Add gfx1034 target Differential Revision: https://reviews.llvm.org/D102306
2021-05-14 02:21:40 +08:00
case ELF::EF_AMDGPU_MACH_AMDGCN_GFX1034:
return "gfx1034";
[AMDGPU] Add gfx1035 target Differential Revision: https://reviews.llvm.org/D104804
2021-06-25 02:32:41 +08:00
case ELF::EF_AMDGPU_MACH_AMDGCN_GFX1035:
return "gfx1035";
[llvm-objdump][AMDGPU] Detect CPU string AMDGPU ISA isn't backwards compatible and hence -mcpu must always be specified during disassembly. However, the AMDGPU target CPU is stored in e_flags in the ELF object. This patch allows targets to implement CPU string detection, and also implements it for AMDGPU by looking at e_flags. Reviewed By: scott.linder Differential Revision: https://reviews.llvm.org/D84519
2020-07-24 17:51:46 +08:00
default:
llvm_unreachable("Unknown EF_AMDGPU_MACH value");
}
}
[ARM] Create objdump subtarget from build attrs Enable an ELFObjectFile to read the its arm build attributes to produce a target triple with a specific ARM architecture. llvm-objdump now uses this functionality to automatically produce a more accurate target. Differential Revision: https://reviews.llvm.org/D28769 llvm-svn: 292366
2017-01-18 21:52:12 +08:00
// FIXME Encode from a tablegen description or target parser.
void ELFObjectFileBase::setARMSubArch(Triple &TheTriple) const {
if (TheTriple.getSubArch() != Triple::NoSubArch)
return;
ARMAttributeParser Attributes;
[ARM] Rewrite ARMAttributeParser * Delete boilerplate * Change functions to return `Error` * Test parsing errors * Update callers of ARMAttributeParser::parse() to check the `Error` return value. Since this patch touches nearly everything in the file, I apply http://llvm.org/docs/Proposals/VariableNames.html and change variable names to lower case. Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D75015
2020-02-22 03:32:33 +08:00
if (Error E = getBuildAttributes(Attributes)) {
// TODO Propagate Error.
consumeError(std::move(E));
[ARM] Create objdump subtarget from build attrs Enable an ELFObjectFile to read the its arm build attributes to produce a target triple with a specific ARM architecture. llvm-objdump now uses this functionality to automatically produce a more accurate target. Differential Revision: https://reviews.llvm.org/D28769 llvm-svn: 292366
2017-01-18 21:52:12 +08:00
return;
[ARM] Rewrite ARMAttributeParser * Delete boilerplate * Change functions to return `Error` * Test parsing errors * Update callers of ARMAttributeParser::parse() to check the `Error` return value. Since this patch touches nearly everything in the file, I apply http://llvm.org/docs/Proposals/VariableNames.html and change variable names to lower case. Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D75015
2020-02-22 03:32:33 +08:00
}
[ARM] Create objdump subtarget from build attrs Enable an ELFObjectFile to read the its arm build attributes to produce a target triple with a specific ARM architecture. llvm-objdump now uses this functionality to automatically produce a more accurate target. Differential Revision: https://reviews.llvm.org/D28769 llvm-svn: 292366
2017-01-18 21:52:12 +08:00
std::string Triple;
// Default to ARM, but use the triple if it's been set.
[Triple] Add isThumb and isARM functions. Summary: isThumb returns true for Thumb triples (little and big endian), isARM returns true for ARM triples (little and big endian). There are a few more checks using arm/thumb that are not covered by those functions, e.g. that the architecture is either ARM or Thumb (little endian) or ARM/Thumb little endian only. Reviewers: javed.absar, rengolin, kristof.beyls, t.p.northover Reviewed By: rengolin Subscribers: llvm-commits, aemerson Differential Revision: https://reviews.llvm.org/D34682 llvm-svn: 310781
2017-08-13 01:40:18 +08:00
if (TheTriple.isThumb())
[ARM] Create objdump subtarget from build attrs Enable an ELFObjectFile to read the its arm build attributes to produce a target triple with a specific ARM architecture. llvm-objdump now uses this functionality to automatically produce a more accurate target. Differential Revision: https://reviews.llvm.org/D28769 llvm-svn: 292366
2017-01-18 21:52:12 +08:00
Triple = "thumb";
else
Triple = "arm";
[RISCV] ELF attribute section for RISC-V. Leverage ARM ELF build attribute section to create ELF attribute section for RISC-V. Extract the common part of parsing logic for this section into ELFAttributeParser.[cpp|h] and ELFAttributes.[cpp|h]. Differential Revision: https://reviews.llvm.org/D74023
2020-02-04 22:20:10 +08:00
Optional<unsigned> Attr =
Attributes.getAttributeValue(ARMBuildAttrs::CPU_arch);
if (Attr.hasValue()) {
switch (Attr.getValue()) {
[ARM] Create objdump subtarget from build attrs Enable an ELFObjectFile to read the its arm build attributes to produce a target triple with a specific ARM architecture. llvm-objdump now uses this functionality to automatically produce a more accurate target. Differential Revision: https://reviews.llvm.org/D28769 llvm-svn: 292366
2017-01-18 21:52:12 +08:00
case ARMBuildAttrs::v4:
Triple += "v4";
break;
case ARMBuildAttrs::v4T:
Triple += "v4t";
break;
case ARMBuildAttrs::v5T:
Triple += "v5t";
break;
case ARMBuildAttrs::v5TE:
Triple += "v5te";
break;
case ARMBuildAttrs::v5TEJ:
Triple += "v5tej";
break;
case ARMBuildAttrs::v6:
Triple += "v6";
break;
case ARMBuildAttrs::v6KZ:
Triple += "v6kz";
break;
case ARMBuildAttrs::v6T2:
Triple += "v6t2";
break;
case ARMBuildAttrs::v6K:
Triple += "v6k";
break;
case ARMBuildAttrs::v7:
Triple += "v7";
break;
case ARMBuildAttrs::v6_M:
Triple += "v6m";
break;
case ARMBuildAttrs::v6S_M:
Triple += "v6sm";
break;
case ARMBuildAttrs::v7E_M:
Triple += "v7em";
break;
[llvm-objdump] Add the missing ARMv8 subarch detection Differential Revision: https://reviews.llvm.org/D66849 llvm-svn: 370163
2019-08-28 14:37:22 +08:00
case ARMBuildAttrs::v8_A:
Triple += "v8a";
break;
case ARMBuildAttrs::v8_R:
Triple += "v8r";
break;
case ARMBuildAttrs::v8_M_Base:
Triple += "v8m.base";
break;
case ARMBuildAttrs::v8_M_Main:
Triple += "v8m.main";
break;
case ARMBuildAttrs::v8_1_M_Main:
Triple += "v8.1m.main";
break;
[ARM] Create objdump subtarget from build attrs Enable an ELFObjectFile to read the its arm build attributes to produce a target triple with a specific ARM architecture. llvm-objdump now uses this functionality to automatically produce a more accurate target. Differential Revision: https://reviews.llvm.org/D28769 llvm-svn: 292366
2017-01-18 21:52:12 +08:00
}
}
if (!isLittleEndian())
Triple += "eb";
TheTriple.setArchName(Triple);
}
Find PLT entries for x86, x86_64, and AArch64. This adds a new method to ELFObjectFileBase that returns the symbols and addresses of PLT entries. This design was suggested by pcc and eugenis in https://reviews.llvm.org/D49383. Differential Revision: https://reviews.llvm.org/D50203 llvm-svn: 340610
2018-08-24 23:21:56 +08:00
[llvm-objdump] Change symbol name/PLT decoding errors to warnings If the referenced symbol of a J[U]MP_SLOT is invalid (e.g. symbol index 0), llvm-objdump -d will bail out: ``` error: 'a': st_name (0x326600) is past the end of the string table of size 0x7 ``` where 0x326600 is the st_name field of the first entry past the end of .symtab Change it to a warning to continue dumping. `X86/plt.test` uses a prebuilt executable, so I pick `ELF/AArch64/plt.test` which has a YAML input and can be easily modified. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D85623
2020-08-13 23:13:26 +08:00
std::vector<std::pair<Optional<DataRefImpl>, uint64_t>>
Find PLT entries for x86, x86_64, and AArch64. This adds a new method to ELFObjectFileBase that returns the symbols and addresses of PLT entries. This design was suggested by pcc and eugenis in https://reviews.llvm.org/D49383. Differential Revision: https://reviews.llvm.org/D50203 llvm-svn: 340610
2018-08-24 23:21:56 +08:00
ELFObjectFileBase::getPltAddresses() const {
std::string Err;
const auto Triple = makeTriple();
const auto *T = TargetRegistry::lookupTarget(Triple.str(), Err);
if (!T)
return {};
uint64_t JumpSlotReloc = 0;
switch (Triple.getArch()) {
case Triple::x86:
JumpSlotReloc = ELF::R_386_JUMP_SLOT;
break;
case Triple::x86_64:
JumpSlotReloc = ELF::R_X86_64_JUMP_SLOT;
break;
case Triple::aarch64:
[llvm-objdump] Support PLT decoding for aarch64_be Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D96211
2021-02-09 00:50:25 +08:00
case Triple::aarch64_be:
Find PLT entries for x86, x86_64, and AArch64. This adds a new method to ELFObjectFileBase that returns the symbols and addresses of PLT entries. This design was suggested by pcc and eugenis in https://reviews.llvm.org/D49383. Differential Revision: https://reviews.llvm.org/D50203 llvm-svn: 340610
2018-08-24 23:21:56 +08:00
JumpSlotReloc = ELF::R_AARCH64_JUMP_SLOT;
break;
default:
return {};
}
Use unique_ptr to hold MCInstrInfo llvm-svn: 340654
2018-08-25 05:03:35 +08:00
std::unique_ptr<const MCInstrInfo> MII(T->createMCInstrInfo());
Use unique_ptr. llvm-svn: 340642
2018-08-25 03:40:35 +08:00
std::unique_ptr<const MCInstrAnalysis> MIA(
Use unique_ptr to hold MCInstrInfo llvm-svn: 340654
2018-08-25 05:03:35 +08:00
T->createMCInstrAnalysis(MII.get()));
Find PLT entries for x86, x86_64, and AArch64. This adds a new method to ELFObjectFileBase that returns the symbols and addresses of PLT entries. This design was suggested by pcc and eugenis in https://reviews.llvm.org/D49383. Differential Revision: https://reviews.llvm.org/D50203 llvm-svn: 340610
2018-08-24 23:21:56 +08:00
if (!MIA)
return {};
Optional<SectionRef> Plt = None, RelaPlt = None, GotPlt = None;
for (const SectionRef &Section : sections()) {
Recommit r368812 "[llvm/Object] - Convert SectionRef::getName() to return Expected<>" Changes: no changes. A fix for the clang code will be landed right on top. Original commit message: SectionRef::getName() returns std::error_code now. Returning Expected<> instead has multiple benefits. For example, it forces user to check the error returned. Also Expected<> may keep a valuable string error message, what is more useful than having a error code. (Object\invalid.test was updated to show the new messages printed.) This patch makes a change for all users to switch to Expected<> version. Note: in a few places the error returned was ignored before my changes. In such places I left them ignored. My intention was to convert the interface used, and not to improve and/or the existent users in this patch. (Though I think this is good idea for a follow-ups to revisit such places and either remove consumeError calls or comment each of them to clarify why it is OK to have them). Differential revision: https://reviews.llvm.org/D66089 llvm-svn: 368826
2019-08-14 19:10:11 +08:00
Expected<StringRef> NameOrErr = Section.getName();
if (!NameOrErr) {
consumeError(NameOrErr.takeError());
Find PLT entries for x86, x86_64, and AArch64. This adds a new method to ELFObjectFileBase that returns the symbols and addresses of PLT entries. This design was suggested by pcc and eugenis in https://reviews.llvm.org/D49383. Differential Revision: https://reviews.llvm.org/D50203 llvm-svn: 340610
2018-08-24 23:21:56 +08:00
continue;
Recommit r368812 "[llvm/Object] - Convert SectionRef::getName() to return Expected<>" Changes: no changes. A fix for the clang code will be landed right on top. Original commit message: SectionRef::getName() returns std::error_code now. Returning Expected<> instead has multiple benefits. For example, it forces user to check the error returned. Also Expected<> may keep a valuable string error message, what is more useful than having a error code. (Object\invalid.test was updated to show the new messages printed.) This patch makes a change for all users to switch to Expected<> version. Note: in a few places the error returned was ignored before my changes. In such places I left them ignored. My intention was to convert the interface used, and not to improve and/or the existent users in this patch. (Though I think this is good idea for a follow-ups to revisit such places and either remove consumeError calls or comment each of them to clarify why it is OK to have them). Differential revision: https://reviews.llvm.org/D66089 llvm-svn: 368826
2019-08-14 19:10:11 +08:00
}
StringRef Name = *NameOrErr;
Find PLT entries for x86, x86_64, and AArch64. This adds a new method to ELFObjectFileBase that returns the symbols and addresses of PLT entries. This design was suggested by pcc and eugenis in https://reviews.llvm.org/D49383. Differential Revision: https://reviews.llvm.org/D50203 llvm-svn: 340610
2018-08-24 23:21:56 +08:00
if (Name == ".plt")
Plt = Section;
else if (Name == ".rela.plt" || Name == ".rel.plt")
RelaPlt = Section;
else if (Name == ".got.plt")
GotPlt = Section;
}
if (!Plt || !RelaPlt || !GotPlt)
return {};
Recommit [Object] Change object::SectionRef::getContents() to return Expected<StringRef> r360876 didn't fix 2 call sites in clang. Expected<ArrayRef<uint8_t>> may be better but use Expected<StringRef> for now. Follow-up of D61781. llvm-svn: 360892
2019-05-16 21:24:04 +08:00
Expected<StringRef> PltContents = Plt->getContents();
if (!PltContents) {
consumeError(PltContents.takeError());
Find PLT entries for x86, x86_64, and AArch64. This adds a new method to ELFObjectFileBase that returns the symbols and addresses of PLT entries. This design was suggested by pcc and eugenis in https://reviews.llvm.org/D49383. Differential Revision: https://reviews.llvm.org/D50203 llvm-svn: 340610
2018-08-24 23:21:56 +08:00
return {};
Recommit [Object] Change object::SectionRef::getContents() to return Expected<StringRef> r360876 didn't fix 2 call sites in clang. Expected<ArrayRef<uint8_t>> may be better but use Expected<StringRef> for now. Follow-up of D61781. llvm-svn: 360892
2019-05-16 21:24:04 +08:00
}
auto PltEntries = MIA->findPltEntries(Plt->getAddress(),
arrayRefFromStringRef(*PltContents),
Find PLT entries for x86, x86_64, and AArch64. This adds a new method to ELFObjectFileBase that returns the symbols and addresses of PLT entries. This design was suggested by pcc and eugenis in https://reviews.llvm.org/D49383. Differential Revision: https://reviews.llvm.org/D50203 llvm-svn: 340610
2018-08-24 23:21:56 +08:00
GotPlt->getAddress(), Triple);
// Build a map from GOT entry virtual address to PLT entry virtual address.
DenseMap<uint64_t, uint64_t> GotToPlt;
for (const auto &Entry : PltEntries)
GotToPlt.insert(std::make_pair(Entry.second, Entry.first));
// Find the relocations in the dynamic relocation table that point to
// locations in the GOT for which we know the corresponding PLT entry.
[llvm-objdump] Change symbol name/PLT decoding errors to warnings If the referenced symbol of a J[U]MP_SLOT is invalid (e.g. symbol index 0), llvm-objdump -d will bail out: ``` error: 'a': st_name (0x326600) is past the end of the string table of size 0x7 ``` where 0x326600 is the st_name field of the first entry past the end of .symtab Change it to a warning to continue dumping. `X86/plt.test` uses a prebuilt executable, so I pick `ELF/AArch64/plt.test` which has a YAML input and can be easily modified. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D85623
2020-08-13 23:13:26 +08:00
std::vector<std::pair<Optional<DataRefImpl>, uint64_t>> Result;
Find PLT entries for x86, x86_64, and AArch64. This adds a new method to ELFObjectFileBase that returns the symbols and addresses of PLT entries. This design was suggested by pcc and eugenis in https://reviews.llvm.org/D49383. Differential Revision: https://reviews.llvm.org/D50203 llvm-svn: 340610
2018-08-24 23:21:56 +08:00
for (const auto &Relocation : RelaPlt->relocations()) {
if (Relocation.getType() != JumpSlotReloc)
continue;
auto PltEntryIter = GotToPlt.find(Relocation.getOffset());
[llvm-objdump] Change symbol name/PLT decoding errors to warnings If the referenced symbol of a J[U]MP_SLOT is invalid (e.g. symbol index 0), llvm-objdump -d will bail out: ``` error: 'a': st_name (0x326600) is past the end of the string table of size 0x7 ``` where 0x326600 is the st_name field of the first entry past the end of .symtab Change it to a warning to continue dumping. `X86/plt.test` uses a prebuilt executable, so I pick `ELF/AArch64/plt.test` which has a YAML input and can be easily modified. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D85623
2020-08-13 23:13:26 +08:00
if (PltEntryIter != GotToPlt.end()) {
symbol_iterator Sym = Relocation.getSymbol();
if (Sym == symbol_end())
Result.emplace_back(None, PltEntryIter->second);
else
Result.emplace_back(Sym->getRawDataRefImpl(), PltEntryIter->second);
}
Find PLT entries for x86, x86_64, and AArch64. This adds a new method to ELFObjectFileBase that returns the symbols and addresses of PLT entries. This design was suggested by pcc and eugenis in https://reviews.llvm.org/D49383. Differential Revision: https://reviews.llvm.org/D50203 llvm-svn: 340610
2018-08-24 23:21:56 +08:00
}
return Result;
}