The round-trip passes were introduced in r193300. The intention of
the change was to make sure that LLD is capable of reading end
writing such file formats.
But that turned out to be yet another over-designed stuff that had
been slowing down everyday development.
The passes ran after the core linker and before the writer. If you
had an additional piece of information that needs to be passed from
front-end to the writer, you had to invent a way to save the data to
YAML/Native. These passes forced us to do that even if that data
was not needed to be represented neither in an object file nor in
an executable/DSO. It doesn't make sense. We don't need these passes.
http://reviews.llvm.org/D7480
llvm-svn: 230069
lldELF is used by each ELF backend. lldELF's ELFLinkingContext
also held a reference to each backend, creating a link-time
cycle. This patch moves the backend references to lldDriver.
Differential Revision: http://reviews.llvm.org/D7119
llvm-svn: 226976
lldELF is used by each ELF backend. lldELF's ELFLinkingContext
also held a reference to each backend, creating a link-time
cycle. This patch moves the backend references to lldDriver.
Differential Revision: http://reviews.llvm.org/D7119
llvm-svn: 226922
If all input files are compatible with Structured Exception Handling, linker
is supposed to create an exectuable with a table for SEH handlers. The table
consists of exception handlers entry point addresses.
The basic idea of SEH in x86 Microsoft ABI is to list all valid entry points
of exception handlers in an read-only memory, so that an attacker cannot
override the addresses in it. In x86 ABI, data for exception handling is mostly
on stack, so it's volnerable to stack overflow attack. In order to protect
against it, Windows runtime uses the table to check a return address, to
ensure that the address is really an valid entry point for an exception handler.
Compiler emits a list of exception handler functions to .sxdata section. It
also emits a marker symbol "@feat.00" to indicate that the object is compatible
with SEH. SEH is a relatively new feature for COFF, and mixing SEH-compatible
and SEH-incompatible objects will result in an invalid executable, so is the
marker.
If all input files are compatible with SEH, LLD emits a SEH table. SEH table
needs to be pointed by Load Configuration strucutre, so when emitting a SEH
table LLD emits it too. The address of a Load Configuration will be stored to
the file header.
llvm-svn: 202248
If the linker is instructed to create a DLL, it will also create an import
library (.lib file) to describe the symbols exported by the DLL. This patch is
to create the import library file.
There is a convenient command "lib.exe" which can create an import library
from a module definition file (.def file). The command is used in this patch.
llvm-svn: 197801
This is the first patch to emit data for the DLL export table. The DLL export
table is the data used by the Windows loader to find the address of exported
function from DLL. With this patch, LLD is able to emit a valid DLL export
table which the Windows loader can interpret and load.
The data structure of the DLL export table is described in the Microsoft
PE/COFF Specification, section 5.3.
DLL support is not complete yet; the linker needs to emit an import library
for a DLL, otherwise the linker cannot link against the DLL. We also do not
support export-only-by-ordinal yet.
llvm-svn: 197212
Also change some local variable names: "ti" -> "context" and
"_targetInfo" -> "_context".
Differential Revision: http://llvm-reviews.chandlerc.com/D1301
llvm-svn: 187823
This is the first patch toward full DLL support. With this patch, lld can
read .lib file for a DLL.
Reviewers: Bigcheese
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D987
llvm-svn: 184101
Add WinLinkDriver and connect it to the existing COFF reader. Remaining
parts are still stubs, so while it can now read a COFF file, it still
cannot link or output PE/COFF files yet.
Reviewers: Bigcheese
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D865
llvm-svn: 182784
now Reader and Writer subclasses for each file format. Each Reader and
Writer subclass defines an "options" class which controls how that Reader
or Writer operates.
llvm-svn: 157774
Rui Ueyama