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

126 lines
3.6 KiB
C++
Raw Normal View History

Object: Add ELF support. llvm-svn: 123896
2011-01-20 14:38:47 +08:00
//===- ELFObjectFile.cpp - ELF object file implementation -------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//
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
//
//===----------------------------------------------------------------------===//
[Object] Split the ELF interface into 3 parts. * ELFTypes.h contains template magic for defining types based on endianess, size, and alignment. * ELFFile.h defines the ELFFile class which provides low level ELF specific access. * ELFObjectFile.h contains ELFObjectFile which uses ELFFile to implement the ObjectFile interface. llvm-svn: 188022
2013-08-09 06:27:13 +08:00
#include "llvm/Object/ELFObjectFile.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"
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
namespace llvm {
using namespace object;
Add support for relocations to ObjectFile. Patch by Danil Malyshev! llvm-svn: 139314
2011-09-09 04:52:17 +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
Use std::unique_ptr to make the ownership explicit. llvm-svn: 214377
2014-07-31 11:12:45 +08:00
ErrorOr<std::unique_ptr<ObjectFile>>
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
ObjectFile::createELFObjectFile(MemoryBufferRef Obj) {
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 =
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
1ULL << countTrailingZeros(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)
return object_error::parse_failed;
Remove 'using std::errro_code' from lib. llvm-svn: 210871
2014-06-13 10:24:39 +08:00
std::error_code EC;
Replace OwningPtr<T> with std::unique_ptr<T>. This compiles with no changes to clang/lld/lldb with MSVC and includes overloads to various functions which are used by those projects and llvm which have OwningPtr's as parameters. This should allow out of tree projects some time to move. There are also no changes to libs/Target, which should help out of tree targets have time to move, if necessary. llvm-svn: 203083
2014-03-06 13:51:42 +08:00
std::unique_ptr<ObjectFile> R;
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)
R.reset(new ELFObjectFile<ELFType<support::little, false>>(Obj, EC));
else if (Ident.second == ELF::ELFDATA2MSB)
R.reset(new ELFObjectFile<ELFType<support::big, false>>(Obj, EC));
else
[Object, ELF] Don't call llvm_unreachable() from createELFObjectFile. Instead, return a proper error code from factory. llvm-svn: 239113
2015-06-05 06:58:25 +08:00
return object_error::parse_failed;
[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)
R.reset(new ELFObjectFile<ELFType<support::little, true>>(Obj, EC));
else if (Ident.second == ELF::ELFDATA2MSB)
R.reset(new ELFObjectFile<ELFType<support::big, true>>(Obj, EC));
else
[Object, ELF] Don't call llvm_unreachable() from createELFObjectFile. Instead, return a proper error code from factory. llvm-svn: 239113
2015-06-05 06:58:25 +08:00
return object_error::parse_failed;
[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 {
return object_error::parse_failed;
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
}
Change relocation API to be per section. This time without breaking GCC. llvm-svn: 141385
2011-10-08 03:25:32 +08:00
Be a bit more consistent about using ErrorOr when constructing Binary objects. The constructors of classes deriving from Binary normally take an error_code as an argument to the constructor. My original intent was to change them to have a trivial constructor and move the initial parsing logic to a static method returning an ErrorOr. I changed my mind because: * A constructor with an error_code out parameter is extremely convenient from the implementation side. We can incrementally construct the object and give up when we find an error. * It is very efficient when constructing on the stack or when there is no error. The only inefficient case is where heap allocating and an error is found (we have to free the memory). The result is that this is a much smaller patch. It just standardizes the create* helpers to return an ErrorOr. Almost no functionality change: The only difference is that this found that we were trying to read past the end of COFF import library but ignoring the error. llvm-svn: 199770
2014-01-22 07:06:54 +08:00
if (EC)
return EC;
Use std::unique_ptr to make the ownership explicit. llvm-svn: 214377
2014-07-31 11:12:45 +08:00
return std::move(R);
Add support for relocations to ObjectFile. Patch by Danil Malyshev! llvm-svn: 139314
2011-09-09 04:52:17 +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
SubtargetFeatures ELFObjectFileBase::getFeatures() const {
switch (getEMachine()) {
case ELF::EM_MIPS: {
SubtargetFeatures Features;
unsigned PlatformFlags;
getPlatformFlags(PlatformFlags);
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;
}
default:
return SubtargetFeatures();
}
}
Object: Add ELF support. llvm-svn: 123896
2011-01-20 14:38:47 +08:00
} // end namespace llvm