22e6648a18
Tools like `install_name_tool` and `codesign` may modify the Mach-O header and increase its size. The linker has to provide padding to make this possible. This diff does that, plus sets its default value to 32 bytes (which is what ld64 does). Unlike ld64, however, we lay out our sections *exactly* `-headerpad` bytes from the header, whereas ld64 just treats the padding requirement as a lower bound. ld64 actually starts laying out the non-header sections in the __TEXT segment from the end of the (page-aligned) segment rather than the front, so its binaries typically have more than `-headerpad` bytes of actual padding. We should consider implementing the same alignment behavior. Reviewed By: #lld-macho, compnerd Differential Revision: https://reviews.llvm.org/D84714
58 lines
1.8 KiB
C++
58 lines
1.8 KiB
C++
//===- Config.h -------------------------------------------------*- C++ -*-===//
|
|
//
|
|
// 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
|
|
//
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
#ifndef LLD_MACHO_CONFIG_H
|
|
#define LLD_MACHO_CONFIG_H
|
|
|
|
#include "llvm/ADT/DenseMap.h"
|
|
#include "llvm/ADT/StringRef.h"
|
|
#include "llvm/BinaryFormat/MachO.h"
|
|
#include "llvm/TextAPI/MachO/Architecture.h"
|
|
|
|
#include <vector>
|
|
|
|
namespace lld {
|
|
namespace macho {
|
|
|
|
class Symbol;
|
|
struct SymbolPriorityEntry;
|
|
|
|
struct Configuration {
|
|
Symbol *entry;
|
|
bool hasReexports = false;
|
|
uint32_t headerPad;
|
|
llvm::StringRef installName;
|
|
llvm::StringRef outputFile;
|
|
llvm::MachO::Architecture arch;
|
|
llvm::MachO::HeaderFileType outputType;
|
|
std::vector<llvm::StringRef> librarySearchPaths;
|
|
std::vector<llvm::StringRef> frameworkSearchPaths;
|
|
llvm::DenseMap<llvm::StringRef, SymbolPriorityEntry> priorities;
|
|
};
|
|
|
|
// The symbol with the highest priority should be ordered first in the output
|
|
// section (modulo input section contiguity constraints). Using priority
|
|
// (highest first) instead of order (lowest first) has the convenient property
|
|
// that the default-constructed zero priority -- for symbols/sections without a
|
|
// user-defined order -- naturally ends up putting them at the end of the
|
|
// output.
|
|
struct SymbolPriorityEntry {
|
|
// The priority given to a matching symbol, regardless of which object file
|
|
// it originated from.
|
|
size_t anyObjectFile = 0;
|
|
// The priority given to a matching symbol from a particular object file.
|
|
llvm::DenseMap<llvm::StringRef, size_t> objectFiles;
|
|
};
|
|
|
|
extern Configuration *config;
|
|
|
|
} // namespace macho
|
|
} // namespace lld
|
|
|
|
#endif
|