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

83 lines
2.0 KiB
C++
Raw Normal View History

Better tie together ContentType and Permissions. Since most content types (e.g. typeCode) have a preferred Permission, add a function to do that mapping. Then hook up to YAML Reader and Writer such that the 'permissions:' key does not need to be specified unless overriding what the content type prefers. llvm-svn: 171929
2013-01-09 09:17:12 +08:00
//===- DefinedAtom.cpp ------------------------------------------*- C++ -*-===//
//
// The LLVM Linker
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
#include "llvm/Support/ErrorHandling.h"
#include "lld/Core/DefinedAtom.h"
ELF: Don't use LayoutPass. Previously we applied the LayoutPass to order atoms and then apply elf::ArrayOrderPass to sort them again. The first pass is basically supposed to sort atoms in the normal fashion (which is to sort symbols in the same order as the input files). The second pass sorts atoms in {init,fini}_array.<priority> by priority. The problem is that the LayoutPass is overkill. It analyzes references between atoms to make a decision how to sort them. It's slow, hard to understand, and above all, it doesn't seem that we need its feature for ELF in the first place. This patch remove the LayoutPass from ELF pass list. Now all reordering is done in elf::OrderPass. That pass sorts atoms by {init,fini}_array, and if they are not in the special section, they are ordered as the same order as they appear in the command line. The new code is far easier to understand, faster, and still able to create valid executables. Unlike the previous layout pass, elf::OrderPass doesn't count any attributes of an atom (e.g. permissions) except its position. It's OK because the writer takes care of them if we have to. This patch changes the order of final output, although that's benign. Tests are updated. http://reviews.llvm.org/D7278 llvm-svn: 227666
2015-01-31 10:05:01 +08:00
#include "lld/Core/File.h"
Better tie together ContentType and Permissions. Since most content types (e.g. typeCode) have a preferred Permission, add a function to do that mapping. Then hook up to YAML Reader and Writer such that the 'permissions:' key does not need to be specified unless overriding what the content type prefers. llvm-svn: 171929
2013-01-09 09:17:12 +08:00
namespace lld {
DefinedAtom::ContentPermissions DefinedAtom::permissions() const {
// By default base permissions on content type.
return permissions(this->contentType());
}
// Utility function for deriving permissions from content type
DefinedAtom::ContentPermissions DefinedAtom::permissions(ContentType type) {
switch (type) {
case typeCode:
case typeResolver:
case typeBranchIsland:
case typeBranchShim:
case typeStub:
case typeStubHelper:
[mach-o] Support linker synthesized mach_header symbols. On darwin in final linked images, the __TEXT segment covers that start of the file. That means in memory a process can see the mach_header (and load commands) for every loaded image in a process. There are APIs that take and return the mach_header addresses as a way to specify a particular loaded image. For completeness, any code can get the address of the mach_header of the image it is in by using &__dso_handle. In addition there are mach-o type specific symbols like __mh_execute_header. The linker needs to supply a definition for any of these symbols if used. But the address the symbol it resolves to is not in any section. Instead it is the address of the start of the __TEXT segment. I needed to make a small change to SimpleFileNode to not override resetNextIndex() because the Driver creates a SimpleFileNode to hold the internal/implicit files that the context/writer can create. For some reason SimpleFileNode overrode resetNextIndex() to do nothing instead of reseting the index (which mach-o needs if the internal file is an archive). llvm-svn: 221822
2014-11-13 06:21:56 +08:00
case typeMachHeader:
Better tie together ContentType and Permissions. Since most content types (e.g. typeCode) have a preferred Permission, add a function to do that mapping. Then hook up to YAML Reader and Writer such that the 'permissions:' key does not need to be specified unless overriding what the content type prefers. llvm-svn: 171929
2013-01-09 09:17:12 +08:00
return permR_X;
[lld] remove trailing whitespace llvm-svn: 177079
2013-03-15 00:09:49 +08:00
Better tie together ContentType and Permissions. Since most content types (e.g. typeCode) have a preferred Permission, add a function to do that mapping. Then hook up to YAML Reader and Writer such that the 'permissions:' key does not need to be specified unless overriding what the content type prefers. llvm-svn: 171929
2013-01-09 09:17:12 +08:00
case typeConstant:
case typeCString:
case typeUTF16String:
case typeCFI:
case typeLSDA:
case typeLiteral4:
case typeLiteral8:
case typeLiteral16:
case typeDTraceDOF:
case typeCompactUnwindInfo:
[mach-o] create __unwind_info section on x86_64 This is a minimally useful pass to construct the __unwind_info section in a final object from the various __compact_unwind inputs. Currently it doesn't produce any compressed pages, only works for x86_64 and will fail if any function ends up without __compact_unwind. rdar://problem/18208653 llvm-svn: 218703
2014-10-01 05:29:54 +08:00
case typeProcessedUnwindInfo:
Add an ObjCPass to the MachO linker. This pass currently emits an objc image info section if one is required. This section contains the aggregated version and flags for all of the input files. llvm-svn: 258197
2016-01-20 05:54:21 +08:00
case typeObjCImageInfo:
Add ObjC method list atom type. NFC. An upcoming patch will use this to create lists of ObjC methods. Adding it now to reduce the amount of code in that patch. Test cases will follow in the other patch too. llvm-svn: 259440
2016-02-02 07:56:27 +08:00
case typeObjCMethodList:
Better tie together ContentType and Permissions. Since most content types (e.g. typeCode) have a preferred Permission, add a function to do that mapping. Then hook up to YAML Reader and Writer such that the 'permissions:' key does not need to be specified unless overriding what the content type prefers. llvm-svn: 171929
2013-01-09 09:17:12 +08:00
return permR__;
case typeData:
add changes for typeDataFast llvm-svn: 175901
2013-02-23 01:18:53 +08:00
case typeDataFast:
Better tie together ContentType and Permissions. Since most content types (e.g. typeCode) have a preferred Permission, add a function to do that mapping. Then hook up to YAML Reader and Writer such that the 'permissions:' key does not need to be specified unless overriding what the content type prefers. llvm-svn: 171929
2013-01-09 09:17:12 +08:00
case typeZeroFill:
[ELF][Hexagon]add typeZeroFillFast llvm-svn: 175983
2013-02-24 11:09:10 +08:00
case typeZeroFillFast:
Better tie together ContentType and Permissions. Since most content types (e.g. typeCode) have a preferred Permission, add a function to do that mapping. Then hook up to YAML Reader and Writer such that the 'permissions:' key does not need to be specified unless overriding what the content type prefers. llvm-svn: 171929
2013-01-09 09:17:12 +08:00
case typeObjC1Class:
case typeLazyPointer:
case typeLazyDylibPointer:
Use __nl_symbol_ptr instead of __got in the stubs pass on x86 archs. The non lazy atoms generated in the stubs pass use an image cache to hold all of the pointers. On arm archs, this is the __got section, but on x86 archs it should be __nl_symbol_ptr. rdar://problem/24572729 llvm-svn: 260271
2016-02-10 04:11:17 +08:00
case typeNonLazyPointer:
Better tie together ContentType and Permissions. Since most content types (e.g. typeCode) have a preferred Permission, add a function to do that mapping. Then hook up to YAML Reader and Writer such that the 'permissions:' key does not need to be specified unless overriding what the content type prefers. llvm-svn: 171929
2013-01-09 09:17:12 +08:00
case typeThunkTLV:
return permRW_;
case typeGOT:
case typeConstData:
case typeCFString:
case typeInitializerPtr:
case typeTerminatorPtr:
case typeCStringPtr:
case typeObjCClassPtr:
case typeObjC2CategoryList:
[mach-o] Add support for interposing tuples section Darwin uses two-level-namespace lookup for symbols which means the static linker records where each symbol must be found at runtime. Thus defining a symbol in a dylib loaded earlier will not effect where symbols needed by later dylibs will be found. Instead overriding is done through a section of type S_INTERPOSING which contains tuples of <interposer, interposee>. llvm-svn: 221421
2014-11-06 09:09:13 +08:00
case typeInterposingTuples:
Better tie together ContentType and Permissions. Since most content types (e.g. typeCode) have a preferred Permission, add a function to do that mapping. Then hook up to YAML Reader and Writer such that the 'permissions:' key does not need to be specified unless overriding what the content type prefers. llvm-svn: 171929
2013-01-09 09:17:12 +08:00
case typeTLVInitialData:
case typeTLVInitialZeroFill:
case typeTLVInitializerPtr:
return permRW_L;
[lld] remove trailing whitespace llvm-svn: 177079
2013-03-15 00:09:49 +08:00
Better tie together ContentType and Permissions. Since most content types (e.g. typeCode) have a preferred Permission, add a function to do that mapping. Then hook up to YAML Reader and Writer such that the 'permissions:' key does not need to be specified unless overriding what the content type prefers. llvm-svn: 171929
2013-01-09 09:17:12 +08:00
case typeUnknown:
case typeTempLTO:
[lld][Darwin] Add support for the -sectcreate option. llvm-svn: 251183
2015-10-24 16:20:51 +08:00
case typeSectCreate:
Fix handling of mach header and DSO handle symbols. The magic file which contained these symbols inherited from archive which meant that the resolver didn't add the required atoms as archive members only get added when referenced. Instead we now inherit from SimpleFile which always links in the atoms needed. The second issue was in the handling of these symbols when we emit the MachO. The mach header symbol needs to be in the atom list as it gets an offset (0), and being in the atom list makes sure it is emitted to the symbol table. DSO handles are not emitted to the symbol table. rdar://problem/24450654 llvm-svn: 259574
2016-02-03 05:37:15 +08:00
case typeDSOHandle:
Better tie together ContentType and Permissions. Since most content types (e.g. typeCode) have a preferred Permission, add a function to do that mapping. Then hook up to YAML Reader and Writer such that the 'permissions:' key does not need to be specified unless overriding what the content type prefers. llvm-svn: 171929
2013-01-09 09:17:12 +08:00
return permUnknown;
}
llvm_unreachable("unknown content type");
}
} // namespace